
\chapter{Computations in functor blocks. II. Semimonads and monads\label{chap:Semimonads-and-monads}}

\global\long\def\gunderline#1{\mathunderline{greenunder}{#1}}%
\global\long\def\bef{\forwardcompose}%
\global\long\def\bbnum#1{\custombb{#1}}%
\global\long\def\pplus{{\displaystyle }{+\negmedspace+}}%

In a Scala programmer\textsf{'}s view, functors are type constructors with
a \lstinline!map! method, filterable type constructors have a \lstinline!filter!
method, and \textbf{semimonads} are functors that have a \lstinline!flatMap!
method. This chapter begins by developing an intuition for the behavior
of \lstinline!flatMap!.

\section{Practical use of monads}

\subsection{Motivation for semimonads: Nested iteration}

How can we translate into code a computation that contains nested
iterations, such as
\begin{equation}
\sum_{i=1}^{n}\sum_{j=1}^{n}\sum_{k=1}^{n}\frac{1}{1+i+j+k}=\,?\label{eq:semimonads-numerical-example-1}
\end{equation}
Recall that a \textsf{``}flat\textsf{''} (non-nested) iteration is translated into
the \lstinline!map! method applied to a sequence:

\begin{wrapfigure}{l}{0.4\columnwidth}%
\vspace{-0.45\baselineskip}
\begin{lstlisting}
(1 to n).map { i => 1.0 / (1 + i) }.sum
\end{lstlisting}
\vspace{-0.5\baselineskip}
\end{wrapfigure}%

~\vspace{-0.6\baselineskip}
\[
\sum_{i=1}^{n}\frac{1}{1+i}\quad.
\]
\vspace{-0.65\baselineskip}

The mathematical notation combines summation and iteration in one
symbol, but the code separates these two steps: first, a sequence
is computed as \lstinline!(1 to n).map { i => 1.0 / (1 + i) }!, holding
the values $\frac{1}{1+i}$ for $i=1,...,n$, and only then the \lstinline!sum!
function is applied to the sequence. This separation is useful because
it gives us full flexibility to transform or aggregate the sequence.

So, we will treat nested iterations in a similar way: first, compute
a sequence of values that result from nested iterations, and then
apply transformations or aggregations to that sequence.

If we use nested \lstinline!map! operations, we will obtain a nested
data structure, e.g., a vector of vectors:
\begin{lstlisting}
scala> (1 to 5).map(i => (1 to i).map(j => i * j))
res0: IndexedSeq[IndexedSeq[Int]] = Vector(Vector(1), Vector(2, 4), Vector(3, 6, 9), Vector(4, 8, 12, 16), Vector(5, 10, 15, 20, 25))
\end{lstlisting}
We need to \textsf{``}flatten\textsf{''} this nested structure into a simple, non-nested
sequence. The standard method for that is \lstinline!flatten!, and
its combination with \lstinline!map! can be replaced by \lstinline!flatMap!:
\begin{lstlisting}
scala> (1 to 4).map(i => (1 to i).map(j => i * j)).flatten
res1: IndexedSeq[Int] = Vector(1, 2, 4, 3, 6, 9, 4, 8, 12, 16)

scala> (1 to 4).flatMap(i => (1 to i).map(j => i * j))     // Same result as above.
res2: IndexedSeq[Int] = Vector(1, 2, 4, 3, 6, 9, 4, 8, 12, 16)
\end{lstlisting}
To represent more nesting, we use more \lstinline!flatMap! operations.
For example, to implement Eq.~(\ref{eq:semimonads-numerical-example-1}):
\begin{lstlisting}
def example(n: Int): Double = (1 to n).flatMap { i =>
  (1 to n).flatMap { j =>
    (1 to n).map { k => 
      1.0 / (1.0 + i + j + k) }
  }
}.sum

scala> example(10)
res3: Double = 63.20950497687006
\end{lstlisting}
These examples show that converting nested iterations into a simple
iteration means replacing all \lstinline!map! functions by \lstinline!flatMap!
except for the last \lstinline!map! call (which by itself produces
a non-nested sequence).

The \lstinline!for!/\lstinline!yield! syntax (or \textsf{``}functor block\textsf{''})
is an easier way of flattening nested iterations: just use a new source
line for each level of nesting. Compare the two following code fragments
line by line:

\noindent \texttt{\textcolor{blue}{\footnotesize{}}}%
\begin{minipage}[c]{0.475\columnwidth}%
\texttt{\textcolor{blue}{\footnotesize{}}}
\begin{lstlisting}
(for { i <- 1 to n
    j <- 1 to n
    k <- 1 to n
  } yield 1.0 / (1.0 + i + j + k)
).sum
\end{lstlisting}
%
\end{minipage}\texttt{\textcolor{blue}{\footnotesize{}\hspace*{\fill}}}%
\begin{minipage}[c]{0.475\columnwidth}%
\texttt{\textcolor{blue}{\footnotesize{}}}
\begin{lstlisting}
(1 to n).flatMap { i =>
   (1 to n).flatMap { j =>
     (1 to n).map { k =>
       1.0 / (1.0 + i + j + k)
  }}}.sum
\end{lstlisting}
%
\end{minipage}{\footnotesize\par}

\vspace{0.2\baselineskip}
The left arrows visually suggest that the variables \lstinline!i!,
\lstinline!j!, \lstinline!k! will iterate over the given sequences.
All left arrows except the last one are replaced by \lstinline!flatMap!s;
the last left arrow is replaced by a \lstinline!map!. These replacements
are performed automatically by the Scala compiler.

A functor block with source lines and conditionals corresponds to
the mathematical notation for creating sets of values. An example
of using that notation is the formula

\begin{wrapfigure}{l}{0.22\columnwidth}%
\vspace{-0.6\baselineskip}
\begin{lstlisting}
val t = for {
  x <- p
  y <- q
  z <- r
  if f(x, y, z) == 0
} yield x + y + z
\end{lstlisting}
\vspace{0.6\baselineskip}
\end{wrapfigure}%

~\vspace{-0.3\baselineskip}
\[
T=\left\{ \left.x+y+z~\right|~x\in P,\,y\in Q,\,z\in R,\,f(x,y,z)=0\,\right\} \quad.
\]
Here, $P$, $Q$, $R$ are given sets of numbers, and the result is
a set $T$ of numbers obtained by adding some $x$ from $P$, some
$y$ from $Q$, and some $z$ from $R$ such that $f(x,y,z)=0$. A
direct implementation of this formula is the code shown at left. Here,
\lstinline!p!, \lstinline!q!, \lstinline!r! are given collections
(say, arrays) and the result \lstinline!t! is again an array. Just
like the mathematical formula\textsf{'}s result is a collection of some $x+y+z$
values, the functor block\textsf{'}s result is a collection of values computed
after the \lstinline!yield! keyword.

To develop more intuition about using functor blocks with multiple
left arrows, look at this code:

\noindent \texttt{\textcolor{blue}{\footnotesize{}}}%
\begin{minipage}[c]{0.475\columnwidth}%
\texttt{\textcolor{blue}{\footnotesize{}}}
\begin{lstlisting}
val result = for {
  i <- 1 to m
  j <- 1 to n
  x = f(i, j)
  k <- 1 to p
  y = g(i, j, k)
} yield h(x, y)
\end{lstlisting}
%
\end{minipage}\texttt{\textcolor{blue}{\footnotesize{}\hspace*{\fill}}}%
\begin{minipage}[c]{0.475\columnwidth}%
\texttt{\textcolor{blue}{\footnotesize{}}}
\begin{lstlisting}
val result = {
  (1 to m).flatMap { i =>
    (1 to n).flatMap { j =>
      val x = f(i, j)
      (1 to p).map { k =>
        val y = g(i, j, k)
        h(x, y)  } } } }
\end{lstlisting}
%
\end{minipage}{\footnotesize\par}

\vspace{0.2\baselineskip}
One can imagine that each line (which we can read as \textsf{``}for all $i$
in $\left[1,...,m\right]$\textsf{''}, \textsf{``}for all $j$ in $\left[1,...,n\right]$\textsf{''},
etc.) will produce an intermediate sequence of the same type. Each
next line continues the calculation from the previous intermediate
sequence. 

If this intuition is correct, we should be able to refactor the code
by cutting the calculation at any place and continuing in another
functor block, without changing the result value:

\noindent \texttt{\textcolor{blue}{\footnotesize{}}}%
\begin{minipage}[c]{0.475\columnwidth}%
\texttt{\textcolor{blue}{\footnotesize{}}}
\begin{lstlisting}
val result = for {
  i <- 1 to m
  j <- 1 to n
// We will cut the block here, making i and j
// available for further computations.
  x = f(i, j)
  k <- 1 to p
  y = g(i, j, k)
} yield h(x, y)
// The `result` is equal to `res2` at right.
\end{lstlisting}
%
\end{minipage}\texttt{\textcolor{blue}{\footnotesize{}\hspace*{\fill}}}%
\begin{minipage}[c]{0.475\columnwidth}%
\texttt{\textcolor{blue}{\footnotesize{}}}
\begin{lstlisting}
val res1 = for {
  i <- 1 to m
  j <- 1 to n
} yield (i, j) // Intermediate sequence `res1`.
val res2 = for {
  (i, j) <- res1   // Continue from `res1`.
  x = f(i, j)
  k <- 1 to p
  y = g(i, j, k)
} yield h(x, y)
\end{lstlisting}
%
\end{minipage}{\footnotesize\par}

\vspace{0.2\baselineskip}
This example illustrates the two features of functor blocks that often
cause confusion:
\begin{itemize}
\item Each \textsf{``}source\textsf{''} line computes an intermediate collection of the
same type, so all values to the right of \lstinline!<-! must use
\emph{the same} type constructor (or its subtypes).
\item The entire functor block\textsf{'}s result is again a collection using the
same type constructor. The result is \emph{not} the expression under
\lstinline!yield!; instead, it is a collection of those expressions.
\end{itemize}
So far, we have been using sequences as the main type constructor.
However, functor blocks with several left arrows will work with any
other type constructor that has \lstinline!map! and \lstinline!flatMap!
methods. In the next sections, we will see how to use functor blocks
with different type constructors. 

Functors having \lstinline!flatMap! methods are called \textbf{semimonads}
in\index{semimonads} this book.\footnote{There is no single accepted name. The libraries \texttt{scalaz} and
\texttt{cats} call the relevant typeclasses \lstinline!Bind! and
\lstinline!FlatMap! respectively.} In practice, most semimonads also have a \lstinline!pure! method
(i.e., belong to the \lstinline!Pointed! typeclass, see Section~\ref{subsec:Pointed-functors:-motivation}).
Semimonads with a \lstinline!pure! method (and obeying the appropriate
laws) are called \textbf{monads}.\index{monads} This chapter will
study semimonads and monads in detail. For now, we note that the functor
block syntax does not require functors to have a \lstinline!pure!
method; it works just as well with semimonads.

If a functor has a \lstinline!withFilter! method, Scala\textsf{'}s functor
block will also support the \lstinline!if! operation (see Section~\ref{sec:Practical-uses-of-filterable-functors}).
So, the full functionality of functor blocks can be used with \emph{filterable
semimonads}.

\subsection{List-like monads}

List-like monads are types that model a collection of data values.
Examples are \lstinline!Seq! and its subtypes, \lstinline!Stream!,
\lstinline!Array!, non-empty lists, sets, and dictionaries. These
data types make different choices of lazy or eager evaluation and
memory allocation, but their \lstinline!flatMap! methods work similarly:
they \textsf{``}flatten\textsf{''} nested collections. 

All list-like monads are also filterable. A typical task for list-like
monads is to find a set of solutions of a combinatorial problem by
first taking all combinations and then filtering out unwanted ones.

\subsubsection{Example \label{subsec:Example-list-monads-1}\ref{subsec:Example-list-monads-1}\index{solved examples}}

Compute all permutations of the three letters \lstinline!"a", "b", "c"!. 

\subparagraph{Solution}

We will compute a \emph{sequence} of all permutations by nested iteration.
First attempt:
\begin{lstlisting}
scala> for {
         x <- Seq("a", "b", "c")
         y <- Seq("a", "b", "c")
         z <- Seq("a", "b", "c")
       } yield x + y + z
res0: Seq[String] = List(aaa, aab, aac, aba, abb, abc, aca, acb, acc, baa, bab, bac, bba, bbb, bbc, bca, bcb, bcc, caa, cab, cac, cba, cbb, cbc, cca, ccb, ccc)
\end{lstlisting}
To obtain all permutations and nothing else, we need to exclude all
repeated subsequences such as \lstinline!"aab"!. To achieve that,
we must make \lstinline!y! iterate over letters that do not include
the current value of \lstinline!x!:
\begin{lstlisting}
val xs = Seq("a", "b", "c")

scala> for {
      x <- xs
      xsWithoutX = xs.filter(_ != x)
      y <- xsWithoutX
      xsWithoutXY = xsWithoutX.filter(_ != y)
      z <- xsWithoutXY
} yield x + y + z
res1: Seq[String] = List(abc, acb, bac, bca, cab, cba) 
\end{lstlisting}


\subsubsection{Example \label{subsec:Example-list-monads-2}\ref{subsec:Example-list-monads-2}}

Compute the set of all subsets of \lstinline!xs = Set("a", "b", "c")!. 

\subparagraph{Solution}

We aim to write the code as a nested iteration. Begin by choosing
one element, say \lstinline!"a"!. Some subsets of \lstinline!xs!
will contain \lstinline!"a"! and other subsets will not. So, let
\lstinline!xa! iterate over two possibilities: either an empty set,
\lstinline!Set()!, or a set containing just \lstinline!"a"!. Then
each subset of \lstinline!xs! is the union of \lstinline!xa! and
some subset that does not contain \lstinline!"a"!. We repeat the
same logic for \lstinline!"b"! and \lstinline!"c"!. The code is:
\begin{lstlisting}
val empty = Set[String]()

scala> for {
         xa <- Set(empty, Set("a"))
         xb <- Set(empty, Set("b"))
         xc <- Set(empty, Set("c"))
       } yield xa ++ xb ++ xc        // p ++ q is the union of the sets p and q.
res0: Set[Set[String]] = Set(Set(), Set(a, b), Set(b, c), Set(a, c), Set(a, b, c), Set(b), Set(c), Set(a))
\end{lstlisting}


\subsubsection{Example \label{subsec:Example-list-monads-3}\ref{subsec:Example-list-monads-3}}

Compute all sub-arrays of length $3$ in a given array. Type signature
and a test:
\begin{lstlisting}
def subarrays3[A](input: IndexedSeq[A]): IndexedSeq[IndexedSeq[A]] = ???

scala> subarrays3(IndexedSeq("a", "b", "c", "d"))
res3: IndexedSeq[IndexedSeq[String]] = Vector(Vector(a, b, c), Vector(a, b, d), Vector(a, c, d), Vector(b, c, d))
\end{lstlisting}


\subparagraph{Solution}

What are the indices of the elements of the required sub-arrays? Suppose
$n$ is the length of the given array. In any sub-array of length
$3$, the first element must have an index $i$ such that $0\leq i<n$.
The second element must have an index $j$ such that $i<j<n$, and
the third element\textsf{'}s index $k$ must satisfy $j<k<n$. So we can iterate
over the indices like this,
\begin{lstlisting}[mathescape=true]
def subarrays3[A](input: IndexedSeq[A]): IndexedSeq[IndexedSeq[A]] = {
  val n = input.length
  for {
    i <- 0 until n                   // Iterate over $\color{dkgreen} 0, 1, ..., n-1$.
    j <- i + 1 until n
    k <- j + 1 until n
  } yield IndexedSeq(input(i), input(j), input(k))
}
\end{lstlisting}


\subsubsection{Example \label{subsec:Example-list-monads-4}\ref{subsec:Example-list-monads-4}}

Generalize examples~\ref{subsec:Example-list-monads-1}\textendash \ref{subsec:Example-list-monads-3}
to support an arbitrary size $n$ instead of $3$.

\subparagraph{Solution}

\textbf{(a)} The task is to compute the set of all permutations of
$n$ letters. We note that the solution in Example~\ref{subsec:Example-list-monads-1}
used three source lines (such as \lstinline!x <- xs!), one for each
letter. To generalize that code to $n$ letters, we would need to
write a functor block with $n$ source lines. However, we cannot do
that if $n$ is a run-time parameter not fixed in advance. So, the
functor block must use recursion in $n$. Begin implementing \lstinline!permutations(xs)!
as a recursive function:
\begin{lstlisting}
def permutations(xs: Seq[String]): Seq[String] = for {
  x <- xs
  xsWithoutX = xs.filter(_ != x)
  ??? permutations(xsWithoutX) ??? // We need to use a recursive call somehow.
\end{lstlisting}
It is promising to use a recursive call of \lstinline!permutations!
with the sub-sequence \lstinline!xsWithoutX! that does not contain
a chosen letter \lstinline!x!. It remains to formulate the code as
nested iteration. Let us visualize the computation for \lstinline!xs == Seq("a","b","c")!.
While iterating over \lstinline!xs!, we start with \lstinline!x == "a"!,
which gives \lstinline!xsWithoutX == Seq("b","c")!. Iterating over
\lstinline!permutations(xsWithoutX)!, we obtain the permutations
\lstinline!"bc"! and \lstinline!"cb"!. These permutations need to
be concatenated with \lstinline!x == "a"!, yielding \lstinline!"abc"!
and \lstinline!"acb"!, which is the correct part of the final answer.
So, we write a nested iteration and concatenate the results:
\begin{lstlisting}
def permutations(xs: Seq[String]): Seq[String] = for {
  x <- xs
  xsWithoutX = xs.filter(_ != x)
  rest <- permutations(xsWithoutX)
} yield x + rest

scala> permutations(Seq("a", "b", "c", "d"))
res0: Seq[String] = List()
\end{lstlisting}
The code is wrong: it always returns an empty list! The reason is
that we provided no base case for the recursion. Eventually the intermediate
value \lstinline!xsWithoutX! becomes empty. A nested iteration with
an empty list always makes the final result also an empty list. To
fix this, add a base case:
\begin{lstlisting}
def permutations(xs: Seq[String]): Seq[String] = if (xs.length == 1) xs else for {
  x <- xs
  xsWithoutX = xs.filter(_ != x)
  rest <- permutations(xsWithoutX)
} yield x + rest

scala> permutations(Seq("a", "b", "c", "d"))
res1: Seq[String] = List(abcd, abdc, acbd, acdb, adbc, adcb, bacd, badc, bcad, bcda, bdac, bdca, cabd, cadb, cbad, cbda, cdab, cdba, dabc, dacb, dbac, dbca, dcab, dcba) 
\end{lstlisting}

\textbf{(b)} To find all subsets of a set via nested iteration, we
cannot directly extend the code from Example~\ref{subsec:Example-list-monads-2}
because we cannot write an unknown number of source lines in a functor
block. As in part \textbf{(a)}, we need to refactor the code and write
a functor block that uses recursion.
\begin{lstlisting}
def subsets[A](xs: Set[A]): Set[Set[A]] = for {
  x <- xs
  xsWithoutX = xs - x           // Use the difference operation for sets.
  ??? subsets(xsWithoutX) ???   // We need to use a recursive call somehow.
\end{lstlisting}
If \lstinline!xs == Set("a", "b", "c")! and \lstinline!x == "a"!
during an iteration, we get \lstinline!xsWithoutX == Set("b", "c")!.
Once we compute \lstinline!subsets(xsWithoutX)!, we need to use all
those subsets together with \lstinline!x! and also without adding
\lstinline!x!. We also should not forget to write the base case (an
empty set \lstinline!xs!). So, the code becomes
\begin{lstlisting}
def subsets[A](xs: Set[A]): Set[Set[A]] = if (xs.isEmpty) Set(xs) else for {
  x <- xs
  xsWithoutX = xs - x
  rest <- subsets(xsWithoutX)   // Recursive call.
  maybeX <- Set(Set(x), Set())
} yield maybeX ++ rest

scala> subsets(Set("a", "b", "c", "d"))
res0: Set[Set[String]] = Set(Set(), Set(a, c, d), Set(a, b), Set(b, c), Set(a, d), Set(a, b, d), Set(b, c, d), Set(a, c), Set(c, d), Set(a, b, c), Set(d), Set(b), Set(b, d), Set(a, b, c, d), Set(c), Set(a)) 
\end{lstlisting}

\textbf{(c)} To compute all sub-arrays of length $n$ from a given
array, we rewrite the solution in Example~\ref{subsec:Example-list-monads-3}
via a recursive function that computes the sequence of indices:
\begin{lstlisting}
def subindices(begin: Int, end: Int, n: Int): IndexedSeq[IndexedSeq[Int]] =
  if (n == 0) IndexedSeq(IndexedSeq()) else for {
    i <- begin until end
    rest <- subindices(i + 1, end, n - 1)   // Recursive call.
  } yield IndexedSeq(i) ++ rest

scala> subindices(0, 4, 2)
res0: IndexedSeq[IndexedSeq[Int]] = Vector(Vector(0, 1), Vector(0, 2), Vector(0, 3), Vector(0, 4), Vector(1, 2), Vector(1, 3), Vector(1, 4), Vector(2, 3), Vector(2, 4), Vector(3, 4))
\end{lstlisting}
The sequence of subarrays is easy to compute once the sequence of
subarray indices is known: 
\begin{lstlisting}
def subarrays[A](n: Int, input: IndexedSeq[A]): IndexedSeq[IndexedSeq[A]] =
  subindices(0, input.length, n).map(_.map(i => input(i)))

scala> subarrays(4, IndexedSeq("a", "b", "c", "d", "e"))
res1: IndexedSeq[IndexedSeq[String]] = Vector(Vector(a, b, c, d), Vector(a, b, c, e), Vector(a, b, d, e), Vector(a, c, d, e), Vector(b, c, d, e))
\end{lstlisting}

The solutions \textbf{(a)}\textendash \textbf{(c)} are not tail recursive
because recursive calls within a source line in a functor block are
translated into recursive calls not in tail positions but \emph{inside}
\lstinline!map! or \lstinline!flatMap! methods. Achieving tail recursion
in functor blocks requires techniques beyond the scope of this chapter.

\subsubsection{Example \label{subsec:Example-list-monads-5}\ref{subsec:Example-list-monads-5}}

Find all solutions of the \textsf{``}$8$ queens\textsf{''} problem.\index{$8$ queens problem}

\subparagraph{Solution}

The $8$ queens must be placed on an $8\times8$ chess board so that
no queen threatens any other queen. To make our work easier, we note
that each queen must be placed in a different row. So, it is sufficient
to find the column index for each queen. A solution is a sequence
of $8$ indices.

Begin by iterating over all possible combinations of column indices:
\begin{lstlisting}
val solutions = for {
  x0 <- 0 until 8              // Queen 0 has coordinates (x0, 0).
  x1 <- 0 until 8              // Queen 1 has coordinates (x1, 1).
  x2 <- 0 until 8              // Queen 2 has coordinates (x2, 2).
\end{lstlisting}
It remains to filter out invalid positions. We should start filtering
as early as possible, since the total number of combinations grows
quickly during nested iterations:
\begin{lstlisting}
val solutions = for {
  x0 <- 0 until 8              // Queen 0 has coordinates (x0, 0).
  x1 <- 0 until 8              // Queen 1 has coordinates (x1, 1).
  if noThreat(x1, Seq(x0))     // Queen 1 does not threaten queen 0.
  x2 <- 0 until 8              // Queen 2 has coordinates (x2, 2).
  if noThreat(x2, Seq(x0, x1)) // Queen 2 does not threaten queens 0 and 1.
  ...
} yield Seq(x0, x1, x2, ...)
\end{lstlisting}
Here, \lstinline!noThreat! is a helper function that decides whether
a new queen threatens previous ones:
\begin{lstlisting}
def noThreat(otherX: Int, prev: Seq[Int]): Boolean = {
  val otherY = prev.length
  prev.zipWithIndex.forall { case (x, y) =>   // Check the vertical and the two diagonals.
    x != otherX && x - y != otherX - otherY && x + y != otherX + otherY
  }
}
\end{lstlisting}
We used a feature of Scala allowing us to pass a sequence of arguments
via the syntax \lstinline!Int*!, which means a variable number of
arguments of type \lstinline!Int!. We can now complete the code and
test it:
\begin{lstlisting}
val column = 0 until 8
val solutions = for {
  x0 <- column                 // Queen 0 has coordinates (x0, 0).
  x1 <- column                 // Queen 1 has coordinates (x1, 1).
  if noThreat(x1, Seq(x0))     // Queen 1 does not threaten queen 0.
  x2 <- column                 // Queen 2 has coordinates (x2, 2).
  if noThreat(x2, Seq(x0, x1)) // Queen 2 does not threaten queens 0 and 1.
  x3 <- column
  if noThreat(x3, Seq(x0, x1, x2))
  x4 <- column
  if noThreat(x4, Seq(x0, x1, x2, x3))
  x5 <- column
  if noThreat(x5, Seq(x0, x1, x2, x3, x4))
  x6 <- column
  if noThreat(x6, Seq(x0, x1, x2, x3, x4, x5))
  x7 <- column
  if noThreat(x7, Seq(x0, x1, x2, x3, x4, x5, x6))
} yield Seq(x0, x1, x2, x3, x4, x5, x6, x7)

scala> solutions.take(5)    // First 5 solutions.
res0: IndexedSeq[Seq[Int]] = Vector(List(0, 4, 7, 5, 2, 6, 1, 3), List(0, 5, 7, 2, 6, 3, 1, 4), List(0, 6, 3, 5, 7, 1, 4, 2), List(0, 6, 4, 7, 1, 3, 5, 2), List(1, 3, 5, 7, 2, 0, 6, 4))
\end{lstlisting}


\subsubsection{Example \label{subsec:Example-list-monads-6}\ref{subsec:Example-list-monads-6}}

Generalize Example~\ref{subsec:Example-list-monads-5} to solve the
\textsf{``}$n$ queens\textsf{''} problem.\index{$n$ queens problem}

\subparagraph{Solution}

In this problem, $n$ queens must be placed on an $n\times n$ chess
board. We need to enumerate and count all solutions.\footnote{There is no known general formula for the number of solutions of the
$n$-queens problem. See a discussion here, \texttt{\href{https://math.stackexchange.com/questions/1872444/}{https://math.stackexchange.com/questions/1872444/}}} As in the $8$-queens problem, each queen must be placed in a different
row, and so we represent a solution by a sequence of $n$ column indices,
each index between $0$ and $n-1$.

Begin by writing code that expects to use itself recursively:
\begin{lstlisting}
def nQueens(n: Int): Seq[Seq[Int]] = for {
  x0 <- 0 until n
  ??? nQueens(n - 1) ???
\end{lstlisting}
Possible positions of new queens depend on the chosen positions for
all previous queens. So, the recursive function must receive that
information. Write an auxiliary recursive function \lstinline!nQueensPartial!
that computes all remaining positions given a sequence of (less than
$n$) previously found queens:
\begin{lstlisting}
def nQueensPartial(n: Int, prev: Seq[Int]): Seq[Seq[Int]] = for {
  x <- 0 until n
  if noThreat(x, prev)         // The new queen does not threaten any previous queens.
  rest <- nQueensPartial(n - 1, prev +: x)    // Find positions with n - 1 new queens.
} yield x +: rest               // Prepend the new queen to the other queen positions.
\end{lstlisting}

This code still has two problems: first, the base case ($n=0$) is
not covered; second, the recursive function must be initially called
with correct arguments. The complete code is
\begin{lstlisting}
def nQueens(n: Int): Seq[Seq[Int]] = {
    def nQueensPartial(m: Int, prev: Seq[Int]): Seq[Seq[Int]] = if (m == 0) Seq(Seq()) else for {
        x <- 0 until n
        if noThreat(x, prev)
        rest <- nQueensPartial(m - 1, prev :+ x)
      } yield x +: rest
    nQueensPartial(n, Seq())
}

scala> (nQueens(8).length, nQueens(9).length, nQueens(10).length, nQueens(11).length)
res0: (Int, Int, Int, Int) = (92,352,724,2680)
\end{lstlisting}


\subsubsection{Example \label{subsec:Example-list-monads-7}\ref{subsec:Example-list-monads-7}{*}}

Formulas of Boolean logic may be transformed by \textsf{``}expanding brackets\textsf{''},
\begin{align*}
{\color{greenunder}\text{expand brackets with a conjunction inside}:}\quad & (a\wedge b)\vee c=\left(a\vee c\right)\wedge\left(b\vee c\right)\quad,\\
{\color{greenunder}\text{expand brackets with a disjunction inside}:}\quad & (a\vee b)\wedge c=\left(a\wedge c\right)\vee\left(b\wedge c\right)\quad.
\end{align*}
Implication is transformed as $(a\Rightarrow b)=((\neg a)\vee b)$.
These transformations (expressed in Scala at left)

\begin{wrapfigure}{l}{0.4\columnwidth}%
\vspace{-0.6\baselineskip}
\begin{lstlisting}
(a && b) || c  ==  (a || c) && (b || c)
(a || b) && c  ==  (a && c) || (b && c)
(a implies b)  ==  (!a) || b
\end{lstlisting}
\vspace{-0.8\baselineskip}
\end{wrapfigure}%

\noindent allow us to rewrite any Boolean formula as a conjunction
of disjunctions with no more nested conjunctions inside, e.g., \lstinline*(a || b) && ((!c) || d || e)*.
This form is called the \textbf{conjunctive normal form}\index{conjunctive normal form}\footnote{\texttt{\href{https://en.wikipedia.org/wiki/Conjunctive_normal_form}{https://en.wikipedia.org/wiki/Conjunctive\_normal\_form}}}
(CNF) of a Boolean formula. We can also rewrite Boolean formula into
a \emph{disjunction} of conjunctions with no more nesting inside,
e.g., \lstinline*(p && q && !r) || ((!x) && y)*. This is called the
\textbf{disjunctive normal form}\index{disjunctive normal form}\footnote{\texttt{\href{https://en.wikipedia.org/wiki/Disjunctive_normal_form}{https://en.wikipedia.org/wiki/Disjunctive\_normal\_form}}}
(DNF) of a Boolean formula. The task is to implement functions that
convert formulas from CNF to DNF and back. 

\subparagraph{Solution}

We begin by designing a data type to represent CNFs. Let the type
parameter $A$ stand for the type of elementary Boolean formulas that
we denoted by \lstinline!a!, \lstinline!b!, \lstinline*!c*, ...,
i.e., Boolean formulas that contain no conjunctions or no disjunctions.
Then we may represent a conjunction as a \lstinline!Set[A]!, and
a disjunction of conjunctions as a \lstinline!Set[Set[A]]!. For instance,
\lstinline!(a || b) && (c || d || e)! is represented by \lstinline!Set(Set(a, b), Set(c, d, e))!.
Because we are using \lstinline!Set!, disjunction of two disjunctions
is easily implemented as a union of sets. Since \lstinline!Set! eliminates
repeated elements, the representation based on \lstinline!Set! will
also automatically perform simplification of formulas such as \lstinline!(a || b || a) == (a || b)!.

Conjunction of two conjunctions may be implemented as a union of sets
for the same reason.

We also need to figure out how to represent the Boolean constants
\lstinline!true! and \lstinline!false! in the CNF. When we compute
a conjunction such as \lstinline!(a || b) && c && true!, the result
must be just \lstinline!(a || b) && c!. Since \lstinline!(a || b) && c!
is represented as \lstinline!Set(Set(a, b), Set(c))!, and since we
compute conjunctions via unions of sets, we expect to have the equation
\begin{lstlisting}
Set(Set(a, b), Set(c)) union Set(???) == Set(Set(a, b), Set(c))
\end{lstlisting}
This must hold for any formulas; so we must represent \lstinline!true!
as an \emph{empty} set of disjunctions, \lstinline!Set()!.

\begin{wrapfigure}{l}{0.4\columnwidth}%
\vspace{-0.6\baselineskip}
\begin{lstlisting}
final case class CNF[A](s: Set[Set[A]])
def trueCNF[A]    = CNF[A](Set())
def falseCNF[A]   = CNF[A](Set(Set()))
\end{lstlisting}
\vspace{-0.8\baselineskip}
\end{wrapfigure}%

The value \lstinline!false! should have the property that for any
group $g$ of disjunctions, e.g., \lstinline!g == (x || y)!, we must
have \lstinline!g || false == g!. So, \lstinline!false! corresponds
to an empty disjunction. However, CNF represents disjunctions by nested
sets contained within conjunctions. Thus, \lstinline!Set(Set())!
must stand for \lstinline!false!.

Similar arguments hold for representing DNFs. We again use nested
sets, but this time the conjunctions and disjunctions are swapped,
so \lstinline!Set(Set(a, b), Set(c, d, e))! stands for the  DNF formula
\lstinline!(a && b) || (c && d && e)!. The value \lstinline!Set()!
represents an empty disjunction and stands for the constant \lstinline!false!,
while the constant \lstinline!true! is \lstinline!Set(Set())!, a
disjunction containing an empty conjunction.

\begin{wrapfigure}{l}{0.4\columnwidth}%
\vspace{-0.6\baselineskip}
\begin{lstlisting}
final case class DNF[A](s: Set[Set[A]])
def trueDNF[A]    = DNF[A](Set(Set()))
def falseDNF[A]   = DNF[A](Set())
\end{lstlisting}
\vspace{-1\baselineskip}
\end{wrapfigure}%

\noindent It is easy to make mistakes when reasoning about the constants
\lstinline!true! and \lstinline!false! in these representations.
We need to test the code to make sure our implementations of \lstinline!true!
and \lstinline!false! are correct.

Before writing the full code, let us implement the DNF-to-CNF conversion
for a short example: 
\begin{lstlisting}
     (a && b) || (c && d)         ---->          (a || c) && (a || d) && (b || c) && (b || d)
                                 // The same formulas are written in the set-based representation as:
DNF(Set(Set(a, b), Set(c, d)))    ---->      CNF(Set(Set(a, c), Set(a, d), Set(b, c), Set(b, d)))
\end{lstlisting}
A simple expression implementing this transformation for nested sets
could look like this: 
\begin{lstlisting}
for {
  x <- Set("a", "b")
  y <- Set("c", "d")
} yield Set(x) ++ Set(y)   // The result is Set(Set(a, c), Set(a, d), Set(b, c), Set(b, d)).
\end{lstlisting}
Generalizing this code to an arbitrary number of nested sets, we get
a first draft of a solution,
\begin{lstlisting}
def toCNF[A](dnf: Set[Set[A]]): Set[Set[A]] = for {
  x  <- dnf.head           // The `head` of a set; corresponds to Set("a", "b") in the example above.
  ys <- toCNF(dnf.tail)    // The `tail` of a set; corresponds to Set(Set("c", "d")) in the example.
                           // Converted to CNF, this corresponds to Set(Set("c"), Set("d")).
} yield Set(x) ++ ys  
\end{lstlisting}
This code is not yet fully correct: we have no base case for the recursion,
and the \lstinline!head! method will crash for an empty set. To make
the pattern matching on a \lstinline!Set! easier, let us implement
a function
\begin{lstlisting}
def headTailOption[A](xs: Set[A]): Option[(A, Set[A])] =     // `List`-like pattern matching for Set.
  if (xs.isEmpty) None else Some((xs.head, xs.tail))
\end{lstlisting}
With that function, we can write the final code as
\begin{lstlisting}
def toCNF[A](dnf: DNF[A]): CNF[A] = headTailOption(dnf.s) match {
  case None => falseCNF[A]     // Base case: The empty set Set() means `false` in DNF.
  case Some((head, tail)) => CNF(for {
    x  <- head                 // The first group of conjunctions.
    ys <- toCNF(DNF(tail)).s   // The remaining groups of conjunctions, recursively converted to CNF.
  } yield ys + x)              // For sets, `ys + x` is the same as `Set(x) ++ ys`.
}                              // Some tests for this code:
val dnf1 = DNF(Set(Set("a", "b"), Set("c", "d", "e")))
val cnf1 = CNF(Set(Set("a", "c"), Set("a", "d"), Set("a", "e"), Set("b", "c"), Set("b", "d"), Set("b", "e")))

scala> toCNF(dnf1) == cnf1
res0: Boolean = true 

scala> (toCNF(trueDNF) == trueCNF, toCNF(falseDNF) == falseCNF)
res1: (Boolean, Boolean) = (true,true)
\end{lstlisting}
Because the rules of Boolean logic are completely symmetric with respect
to swapping the operations $\vee$ and $\wedge$, the function \lstinline!cnf2dnf!
can be implemented via \lstinline!dnf2cnf! like this,
\begin{lstlisting}
def toDNF[A](cnf: CNF[A]): DNF[A] = DNF(toCNF(DNF(cnf.s)).s)

scala> (toDNF(trueCNF) == trueDNF, toDNF(falseCNF) == falseDNF)
res2: (Boolean, Boolean) = (true,true)
\end{lstlisting}

If we test some more, we will find that the functions \lstinline!toCNF!
and \lstinline!toDNF! are not inverses:
\begin{lstlisting}
scala> toDNF(cnf1)     // Expected this to equal DNF(Set(Set("a", "b"), Set("c", "d", "e"))) == dnf1.
res3: DNF[String] = DNF(Set(Set(b, a), Set(b, a, c, e), Set(d, a, b), Set(b, e, a), Set(b, a, c), Set(d, e, c, b), Set(d, e, c), Set(d, a, c, b), Set(e, a, b, c, d), Set(d, a, e, c), Set(d, a, e, b)))
\end{lstlisting}
However, we already verified that \lstinline!cnf1 == toCNF(dnf1)!.
We expect the formula \lstinline!dnf1! to remain the same when we
convert it to CNF and back to DNF. Why the discrepancy? The reason
is that the transformations \lstinline!toDNF! and \lstinline!toCNF!
fail to perform certain simplifications allowed in Boolean logic.
For example, both \lstinline!(a) || (a && b)! and \lstinline!(a) && (a || b)!
are equivalent to just \lstinline!(a)!. In the set-based representations,
we must be able to simplify \lstinline!Set(Set("a"), Set("a", "b"))!
to just \lstinline!Set(Set("a"))!. Generally, we may discard any
conjunction group that happens to be a superset of another conjunction
group, and similarly for disjunction groups. After these simplifications,
the formula \lstinline!toDNF(cnf1)! becomes equal to \lstinline!dnf1!
because, as we can see, all inner sets in \lstinline!toDNF(cnf1)!
are supersets of either \lstinline!Set("a", "b")! or \lstinline!Set("c", "d", "e")))!
or both. We can implement the simplifications as a function \lstinline!simplifyCNF!:
\begin{lstlisting}
def simplifyCNF[A](cnf: CNF[A]): CNF[A] = CNF(
    cnf.s.toIndexedSeq.sortBy(_.size).foldLeft(Set[Set[A]]()) { case (prevGroups, group) =>
        if (prevGroups.exists(_ subsetOf group)) prevGroups else prevGroups + group
      }    // Omit `group` if it happens to be a superset of some previous group within `prevGroups`.
)    // Since `prevGroups` is sorted by group size, we only need to check later groups for supersets.

scala> simplifyCNF(CNF(Set(Set("a", "b"), Set("a", "b", "c", "d"))))
res3: CNF[String] = CNF(Set(Set(a, b)))
\end{lstlisting}
With this function, we may define more practically useful transformations
\lstinline!dnf2cnf! and \lstinline!cnf2dnf! as
\begin{lstlisting}
def dnf2cnf[A](dnf: DNF[A]): CNF[A] = simplifyCNF(toCNF(dnf))
def cnf2dnf[A](cnf: CNF[A]): DNF[A] = DNF(dnf2cnf(DNF(cnf.s)).s)
                                                     // Verify that dnf2cnf and cnf2dnf are inverses:
scala> (dnf2cnf(cnf2dnf(cnf1)) == cnf1, cnf2dnf(dnf2cnf(dnf1)) == dnf1)
res4: (Boolean, Boolean) = (true,true)
\end{lstlisting}
The new conversion functions \lstinline!dnf2cnf! and \lstinline!cnf2dnf!
are inverses of each other.

\subsubsection{Example \label{subsec:Example-matrix-products}\ref{subsec:Example-matrix-products}{*}
(matrix operations)}

If matrices are represented by nested sequences of numbers, matrix
products can be calculated via nested functor blocks. The present
task is to implement: \textbf{(a)} matrix transposition, \textbf{(b)}
the vector-matrix dot product, and \textbf{(c)} the matrix-matrix
dot product.

\subparagraph{Solution}

\textbf{(a)} If a matrix has type \lstinline!Seq[Seq[A]]!, a transposed
matrix has the same type. An example:

\begin{wrapfigure}{l}{0.65\columnwidth}%
\vspace{-0.85\baselineskip}
\begin{lstlisting}
val matrix = Seq(                    val matrix_T = Seq(
               Seq(1, 2, 3),                          Seq(1, 10),
               Seq(10, 20, 30)                        Seq(2, 20),
             )                                        Seq(3, 30)
/* Both matrices have type Seq[Seq[Int]]. */        )
\end{lstlisting}
\vspace{-0.95\baselineskip}
\end{wrapfigure}%

\noindent To compute the transposed matrix, we have to iterate over
the initial matrix. A functor block of type \lstinline!Seq! will
return a value of type \lstinline!Seq[Seq[A]]! only if the \lstinline!yield!
expression itself returns a value of type \lstinline!Seq[A]!. The
example above shows that the first iteration should return \lstinline!Seq(1, 10)!,
which contains the first elements of all inner sequences from \lstinline!matrix!.
The second iteration should return all second elements, and so on.
We see that we need to iterate over the indices of the matrix columns.
Those indices are returned by the library method \lstinline!indices!:
\begin{lstlisting}
scala> Seq("Wilhelm Roentgen", "Henri Beckerel", "Marie Curie").indices
res0: scala.collection.immutable.Range = Range(0, 1, 2)
\end{lstlisting}
The value \lstinline!Seq(1, 10)! can be computed by the functor block
\begin{lstlisting}
for { row <- matrix } yield row(0)
\end{lstlisting}
This functor block needs to be written \emph{inside} the \lstinline!yield!
value of the iterations of the indices:
\begin{lstlisting}
scala> val matrix_T = for { index <- matrix.head.indices }    // [0, 1, 2] are the column indices.
                      yield { for { row <- matrix }        // Iterate over the rows of the matrix.
                              yield row(index)
                            }
matrix_T: IndexedSeq[Seq[Int]] = Vector(List(1, 10), List(2, 20), List(3, 30))
\end{lstlisting}

The two nested \lstinline!for!/\lstinline!yield! blocks represent
two nested loops whose result value is again a nested sequence. We
have implemented nested loops over column and row indices by nested
functor blocks that use the column indices but directly iterate over
rows.

\textbf{(b)} To see how a vector-matrix dot product works, consider
this example:
\[
\left|\begin{array}{ccc}
a_{0} & a_{1} & a_{2}\end{array}\right|\cdot\left|\begin{array}{cc}
b_{00} & b_{01}\\
b_{10} & b_{11}\\
b_{20} & b_{21}
\end{array}\right|=\left|\begin{array}{cc}
a_{0}\cdot b_{00}+a_{1}\cdot b_{10}+a_{2}\cdot b_{20} & a_{0}\cdot b_{01}+a_{1}\cdot b_{11}+a_{2}\cdot b_{21}\end{array}\right|\quad.
\]
The $2\times3$ matrix is represented as a sequence containing three
nested sequences. We need to iterate over the first elements of the
nested sequences ($b_{00}$, $b_{10}$, $b_{20}$) , multiply them
with the corresponding elements ($a_{0}$, $a_{1}$, $a_{2}$) of
the vector, and compute the sum of all products. The code for that
is
\begin{lstlisting}
Seq(b00, b10, b20).zip(Seq(a0, a1, a2)).map { case (x, y) => x * y }.sum
\end{lstlisting}
Then we need to do the same with the second elements ($b_{01}$, $b_{11}$,
$b_{21}$). To obtain the full code, we iterate over the indices of
the nested sequences, as we did in part \textbf{(a)} for the transposition:
\begin{lstlisting}
import scala.math.Numeric.Implicits.infixNumericOps
def vectorMatrixProduct[N: Numeric](vector: Seq[N], matrix: Seq[Seq[N]]): Seq[N] =
  for { index <- matrix.head.indices } yield {
    val b = for { row <- matrix } yield row(index)
    val pairs = for { (x, y) <- b.zip(vector) } yield x * y 
    pairs.sum
  }

scala> vectorMatrixProduct(Seq(3,4,5), matrix_T)
res1: Seq[Int] = Vector(26, 260)
\end{lstlisting}

\textbf{(c)} The matrix-matrix dot product is defined as a matrix
containing the results of the vector-matrix dot products, for all
row vectors of the first matrix. For example,
\[
\left|\begin{array}{ccc}
a_{00} & a_{01} & a_{02}\\
a_{10} & a_{11} & a_{12}
\end{array}\right|\cdot\left|\begin{array}{cc}
b_{00} & b_{01}\\
b_{10} & b_{11}\\
b_{20} & b_{21}
\end{array}\right|=\left|\begin{array}{cc}
a_{00}\cdot b_{00}+a_{01}\cdot b_{10}+a_{02}\cdot b_{20} & a_{00}\cdot b_{01}+a_{01}\cdot b_{11}+a_{02}\cdot b_{21}\\
a_{10}\cdot b_{00}+a_{11}\cdot b_{10}+a_{12}\cdot b_{20} & a_{10}\cdot b_{01}+a_{11}\cdot b_{11}+a_{12}\cdot b_{21}
\end{array}\right|\quad.
\]
We reuse the solution of part \textbf{(b)} and write the code as
\begin{lstlisting}
def matrixProduct[N: Numeric](matrix1: Seq[Seq[N]], matrix2: Seq[Seq[N]]): Seq[Seq[N]] =
  for { row1 <- matrix1 } yield vectorMatrixProduct(row1, matrix2)
\end{lstlisting}

The code shown in this example is for illustration only; for higher
performance, matrix operations must be implemented through flat arrays
rather than nested sequences.

\subsubsection{Exercise \label{subsec:Exercise-m-matrix-vector-dot-product}\ref{subsec:Exercise-m-matrix-vector-dot-product}\index{exercises}}

Implement the matrix-vector dot product as a function
\begin{lstlisting}
def matrixVectorProduct[N: Numeric](matrix: Seq[Seq[N]], vector: Seq[N]): Seq[N] = ???
\end{lstlisting}
The result of computing the matrix-vector product is a column vector,
for example:
\[
\left|\begin{array}{ccc}
a_{00} & a_{01} & a_{02}\\
a_{10} & a_{11} & a_{12}
\end{array}\right|\cdot\left|\begin{array}{c}
b_{00}\\
b_{10}\\
b_{20}
\end{array}\right|=\left|\begin{array}{c}
a_{00}\cdot b_{00}+a_{01}\cdot b_{10}+a_{02}\cdot b_{20}\\
a_{10}\cdot b_{00}+a_{11}\cdot b_{10}+a_{12}\cdot b_{20}
\end{array}\right|\quad.
\]


\subsubsection{Exercise \label{subsec:Exercise-m-matrix-trace}\ref{subsec:Exercise-m-matrix-trace}}

The \textbf{trace} of a square matrix\index{trace of a matrix} is
the sum of its diagonal elements, e.g.:
\[
\text{Tr}\,\left|\begin{array}{ccc}
a_{00} & a_{01} & a_{02}\\
a_{10} & a_{11} & a_{12}\\
a_{20} & a_{21} & a_{22}
\end{array}\right|\triangleq a_{00}+a_{11}+a_{22}\quad.
\]
Implement the trace of a matrix (assuming a square matrix) as a function
\begin{lstlisting}
def trace[N: Numeric](matrix: Seq[Seq[N]]): N = ???
\end{lstlisting}


\subsection{Pass/fail monads}

The type \lstinline!Option[A]! can be viewed as a collection that
can either empty or hold a single value of type \lstinline!A!. An
\textsf{``}iteration\textsf{''} over such a collection will perform a computation
at most once:
\begin{lstlisting}
scala> for { x <- Some(123) } yield x * 2     // The computation is performed once.
res0: Option[Int] = Some(246) 
\end{lstlisting}
When an \lstinline!Option! value is empty, the computation is not
performed at all.
\begin{lstlisting}
scala> for { x <- None: Option[Int] } yield x * 2     // The computation is not performed at all.
res1: Option[Int] = None
\end{lstlisting}
What would a \emph{nested} \textsf{``}iteration\textsf{''} over several \lstinline!Option!
values do? When all of the \lstinline!Option! values are non-empty,
the \textsf{``}iteration\textsf{''} will perform some computations using the wrapped
values. However, if even one of the \lstinline!Option! values happens
to be empty, the computed result will be an empty value:
\begin{lstlisting}
scala> for {
         x <- Some(123)
         y <- None
         z <- Some(-1)
       } yield x + y + z
res2: Option[String] = None
\end{lstlisting}

Computations with \lstinline!Either! and \lstinline!Try! values
follow the same logic: nested \textsf{``}iteration\textsf{''} will perform no computations
unless all values are non-empty. This logic is useful for implementing
a series of computations that could produce failures, where any failure
should stop all further processing. For this reason (and since they
all support the \lstinline!pure! method and are lawful monads, as
this chapter will show), we call the type constructors \lstinline!Option!,
\lstinline!Either!, and \lstinline!Try! the \textbf{pass/fail monads}. 

The following schematic example illustrates this logic:
\begin{lstlisting}
val result: Try[A] = for { // Computations in the `Try` monad.
  x <- Try(k())            // First computation `k()`, may fail.
  y = f(x)                 // No possibility of failure in this line.
  if p(y)                  // The entire expression will fail if `p(y) == false`.
  z <- Try(g(x, y))        // The computation may also fail here.
  r <- Try(h(x, y, z))     // May fail here as well.
} yield r                  // If `r` has type `A` then `result` has type `Try[A]`.
\end{lstlisting}
The function \lstinline!Try()! catches exceptions thrown by its argument.
If one of \lstinline!k()!, \lstinline!g(x, y)!, or \lstinline!h(x, y, z)!
throws an exception, the corresponding \lstinline!Try(...)! value
will evaluate to a \lstinline!Failure(...)! case class, and further
computations will not be performed. The value \lstinline!result!
will indicate the \emph{first} encountered failure. Only if all \lstinline!Try(...)!
values evaluate to a \lstinline!Success(...)! case class, the entire
expression evaluates to a \lstinline!result! of type \lstinline!Success!
that wraps a value of type \lstinline!A!.

Whenever this pattern of computation is found, a functor block gives
concise and readable code that replaces a series of nested \lstinline!if!/\lstinline!else!
or \lstinline!match!/\lstinline!case! expressions. A typical situation
was shown in Example~\ref{subsec:disj-Example-resultA} (Chapter~\ref{chap:Disjunctive-types}),
where a \textsf{``}safe integer\textsf{''} computation continues only as long as every
result is a success; the chain of operations stops at the first failure.
The code of Example~\ref{subsec:disj-Example-resultA} introduced
custom data type with hand-coded methods such as \lstinline!add!,
\lstinline!mul!, and \lstinline!div!. We can now implement equivalent
functionality using functor blocks and a standard type \lstinline!Either[String, Int]!:
\begin{lstlisting}
type Result = Either[String, Int]
def div(x: Int, y: Int): Result = if (y == 0) Left(s"error: $x / $y") else Right(x / y)
def sqrt(x: Int): Result = if (x < 0) Left(s"error: sqrt($x)") else Right(math.sqrt(x).toInt)
val previous: Result = Right(20)  // Start with some given `previous` value of type `Result`.

scala> val result: Result = for {  // Safe computation: `sqrt(1000 / previous - 100) + 20`.
  x <- previous
  y <- div(1000, x)
  z <- sqrt(y - 100)
} yield z + 1
result: Result = Left("error: sqrt(-50)")
\end{lstlisting}
The concise and readable code of \lstinline!val result! replaces
more verbose implementations such as
\begin{lstlisting}
val result: Result = previous match {
  case Left(error)   => Left(error)
  case Right(x)      => div(1000, x) match {
    case Left(error)   => Left(error)
    case Right(y)      => sqrt(y - 100) match {
      case Left(error)   => Left(error)
      case Right(z)      => ...   // More repetitive code of this sort.
\end{lstlisting}

The following examples illustrate the typical tasks where pass/fail
monads are used. These tasks perform a linear sequence of computations
that may fail; the first failure is then returned as a value.

\subsubsection{Example \label{subsec:Example-:chain-with-option}\ref{subsec:Example-:chain-with-option}:
chaining computations with \texttt{Option}\index{solved examples}}

Some clients have placed some orders with some companies. The information
is made available via Java system properties, for example:
\begin{lstlisting}
System.setProperty("client 0", "company 2")
System.setProperty("client 1", "company 3")
System.setProperty("company 2", "order 4")
System.setProperty("company 3", "order 5")
System.setProperty("order 4", "123")
System.setProperty("order 5", "456")
\end{lstlisting}
Given a client\textsf{'}s name, obtain the corresponding order quantity if
it exists.

\subparagraph{Solution}

The Java method \lstinline!System.getProperty! returns the property
value as \lstinline!String! if the property is present, and otherwise
returns \lstinline!null!. Wrapping that return value into an \lstinline!Option()!
call, we replace null values by empty \lstinline!Option! values (i.e.,
\lstinline!None!). This makes the result values safe: using a \lstinline!null!
value may throw an exception, which will not happen when using \lstinline!map!
and \lstinline!flatMap! methods on \lstinline!Option! values. It
remains to chain the computations:

\begin{lstlisting}
def getOrderAmount(client: String): Option[Int] =   for {
      company     <- Option(System.getProperty(client))
      order       <- Option(System.getProperty(company))
      stringValue <- Option(System.getProperty(orders))
      intValue    <- Try(stringValue.toInt).toOption      // Non-integer string values are invalid.
    } yield intValue

scala> getOrderAmount("client 1")
res0: Option[Int] = Some(123)

scala> getOrderAmount("client 2")
res1: Option[Int] = Some(456)

scala> getOrderAmount("client 3")
res2: Option[Int] = None
\end{lstlisting}

In the example just shown, \lstinline!Option! values are sufficient
since the absence of a property is not an error situation. Now we
consider a task where we need to keep track of error information.

\subsubsection{Example \label{subsec:Example-:chain-with-option-1}\ref{subsec:Example-:chain-with-option-1}:
chaining computations with \texttt{Try}}

Three given functions $f$, $g$, $h$ all have Scala type \lstinline!Int => Int!
but may throw exceptions. Given an integer $x$, compute $f(g(h(x)))$
safely, reporting the first encountered error.

\subparagraph{Solution}

Wrap each function into a \lstinline!Try()! and chain the resulting
computations:
\begin{lstlisting}
def f(x: Int): Int = 1 / x
def g(x: Int): Int = 2 - x
def h(x: Int): Int = 2 / x

import scala.util.Try
def result(x: Int): Try[Int] = for {
      p <- Try(h(x))
      q <- Try(g(p))
      r <- Try(f(q))
    } yield r

scala> result(1)
res0: Try[Int] = Failure(java.lang.ArithmeticException: / by zero)
\end{lstlisting}
The result value shows information about the failure generated in
this computation.

\subsubsection{Example \label{subsec:Example-chaining-future}\ref{subsec:Example-chaining-future}:
chaining with \texttt{Future}}

Scala library\textsf{'}s \lstinline!Future! class can be seen as a pass/fail
monad because \lstinline!Future(x)! will encapsulate any exception
thrown while computing \lstinline!x!. However, in addition to the
pass/fail features, a \lstinline!Future! value has a concurrency
effect: the encapsulated computation \lstinline!x! is scheduled to
be run in parallel on another CPU thread. For this reason, \lstinline!Future!\textsf{'}s
methods (such as \lstinline!map! and \lstinline!flatMap!) require
an implicit \lstinline!ExecutionContext! argument, which provides
access to a JVM thread pool where computations will be scheduled.

As soon as a \lstinline!Future! value is created, its computation
is scheduled immediately. So, several \lstinline!Future! values may
run their computations in parallel. Nevertheless, computations chained
via \lstinline!flatMap! (or in a functor block) will run sequentially
if new values need to wait for previous values:
\begin{lstlisting}
import scala.concurrent.ExecutionContext.Implicits.global
def longComputation(x: Double): Future[Double] = Future { ... } // A long computation.

val result1: Future[Double] = for {
  p <- longComputation(10.0)
  q <- longComputation(p + 20.0)
  r <- longComputation(q - 20.0)
} yield p + q + r  // Three `longComputation` calls are running sequentially.
\end{lstlisting}
This code waits for the first \lstinline!Future! that computes \lstinline!p!,
then creates a \lstinline!Future! value that will eventually compute
\lstinline!q!, and finally creates a \lstinline!Future! that will
eventually compute \lstinline!r!; only then the sum \lstinline!p + q + r!
may be obtained (wrapped in a \lstinline!Future! constructor). This
computation cannot run the three \lstinline!longComputation(...)!
calls in parallel, since each call depends on the result of the previous
one.

Another possibility is that each \lstinline!longComputation(...)!
is independent of the results of the other computations. Then the
three \lstinline!Future! values may be created up front, and the
functor block code represents three \textsf{``}long computations\textsf{''} running
in parallel:
\begin{lstlisting}
val long1 = longComputation(10.0)
val long2 = longComputation(50.0)
val long3 = longComputation(100.0)

val result2: Future[Double] = for {
  p <- long1
  q <- long2
  r <- long3
} yield p + q + r  // Three `longComputation()` calls are running in parallel.
\end{lstlisting}


\subsection{Tree-like semimonads and monads\label{subsec:Tree-like-semimonads-and-monads}}

Tree-like type constructors are recursive types such as those described
in Section~\ref{sec:Lists-and-trees:recursive-disjunctive-types}.
A typical example of a tree-like type constructor is the binary tree
defined by the type equation
\[
\text{BT}^{A}\triangleq A+\text{BT}^{A}\times\text{BT}^{A}.
\]
Statement~\ref{subsec:functor-Statement-functor-composition-1} shows
that $\text{BT}^{A}$ is a functor by replacing the right-hand side
$A+\text{BT}^{A}\times\text{BT}^{A}$ by an arbitrary \textsf{``}structure
bifunctor\textsf{''} $S^{A,\text{BT}^{A}}$ and then showing that the recursive
type constructor $L^{A}$ defined by $L^{A}\triangleq S^{A,L^{A}}$
is a functor. As we will see, the type constructor $L^{A}$ will be
a semimonad or a monad with certain choices of $S^{\bullet,\bullet}$.

For lists, nested iteration goes over inner lists contained in an
outer list. How does nested iteration work for a tree-shaped collection?
An iteration over a tree enumerates the values at the \emph{leaves}
of a tree. So, a tree analog of nested iteration implies that each
leaf of an outer tree contains an inner tree. A \lstinline!flatMap!
function must concatenate all nested trees into a single \textsf{``}flattened\textsf{''}
tree. 

Let us implement the \lstinline!flatMap! method for the binary tree
$BT^{\bullet}$ in that way. It is convenient to define an equivalent
curried function (denoted by \textsf{``}$\text{flm}$\textsf{''}) with type signature
\[
\text{flm}^{A,B}:(A\rightarrow\text{BT}^{B})\rightarrow\text{BT}^{A}\rightarrow\text{BT}^{B}\quad.
\]
\begin{lstlisting}[numbers=left]
sealed trait BTree[A]
final case class Leaf[A](x: A) extends BTree[A]
final case class Branch[A](b1: BTree[A], b2: BTree[A]]) extends BTree[A]

def flm[A, B](f: A => BTree[B]): BTree[A] => BTree[B] = {             // t.flatMap(f) == flm(f)(t)
  case Leaf(x)          => f(x) // Here f(x) has type BTree[B], which could be a Leaf or a Branch.
  case Branch(b1, b2)   => Branch(flm(f)(b1), flm(f)(b2))             // Recursive calls of `flm`.
}
\end{lstlisting}
The same implementation is written in the code notation as
\[
\text{flm}^{A,B}(f^{:A\rightarrow\text{BT}^{B}})\triangleq\,\begin{array}{|c||c|}
 & B+\text{BT}^{B}\times\text{BT}^{B}\\
\hline A & f\\
\text{BT}^{A}\times\text{BT}^{A} & b_{1}\times b_{2}\rightarrow\bbnum 0^{:B}+\overline{\text{flm}}(f)(b_{1})\times\overline{\text{flm}}(f)(b_{2})
\end{array}\quad.
\]

To visualize how the \lstinline!flatMap! method operates on binary
trees,  let us compute \lstinline!tree1.flatMap(f)!, where we take
\lstinline!tree1 = ! \Tree[  [ $a_1$ ] [ [ $a_2$ ] [ $a_3$ ] ] ] 
and a function $f:A\rightarrow\text{BT}^{B}$ that has $f(a_{1})=$ \Tree[  [ $b_0$ ] [ $b_1$ ] ] ,
$f(a_{2})=b_{2}$, and $f(a_{3})=$ \Tree[  [ $b_3$ ] [ $b_4$ ] ]\relax.
(Here $a_{i}$ for $i=1,2,3$ are some values of type $A$ and $b_{i}$
for $i=0,...,4$ are some values of type $B$.) Evaluating the code
of \lstinline!flatMap!, we find \lstinline!tree1.flatMap(f)! = \Tree[  [ [ $b_0$ ] [ $b_1$ ] ] [ [ $b_2$ ] [ [ $b_3$ ] [ $b_4$ ] ] ] ]\relax. 

So, we see that \lstinline!flatMap! works by grafting a subtree into
every \lstinline!Leaf! of a given tree: A leaf is replaced by a new
tree in line~6 in the code of \lstinline!flatMap!. That code can
be generalized to the recursive type $\text{PT}^{A}$ (representing
a \textsf{``}tree with $P$-shaped branches\textsf{''}) defined by
\[
\text{PT}^{A}\triangleq A+P^{\text{PT}^{A}}\quad,
\]
for any given functor $P$. The disjunctive part $A+\bbnum 0$ is
replaced by a new tree:
\begin{lstlisting}
sealed abstract class PTree[P[_] : Functor, A] // Need an `abstract class` due to implicits.
final case class Leaf[P[_] : Functor, A](x: A) extends PTree[P, A]
final case class Branch[P[_] : Functor, A](p: P[PTree[P, A]]) extends PTree[P, A]

def flm[P[_]: Functor, A, B](f: A => PTree[P, B]): PTree[P, A] => PTree[P, B] = {
  case Leaf(x)      => f(x)  // Here f(x) has type PTree, which could be a Leaf or a Branch.
  case Branch(p)    => Branch(p.map(t => flm(f)(t))  // Conceptually, Branch(p.map(flm(f))). 
}
\end{lstlisting}
The same function is written in the code notation as
\[
\text{flm}^{A,B}\big(f^{:A\rightarrow P^{\text{PT}^{B}}}\big)\triangleq\,\begin{array}{|c||c|}
 & B+P^{\text{PT}^{B}}\\
\hline A & f\\
P^{\text{PT}^{A}} & \big(\overline{\text{flm}}\,(f)\big)^{\uparrow P}
\end{array}\quad.
\]

We can also implement \lstinline!flatMap! for more general type constructors
$L$ defined by $L^{A}\triangleq P^{A}+P^{L^{A}}$ for some functor
$P$. Such $L^{A}$ can be visualized as trees with $P$-shaped branches
and $P$-shaped leaves.
\begin{lstlisting}
sealed abstract class PLPT[P[_] : Functor, A]
final case class Leaf[P[_] : Functor, A](px: P[A]) extends PLPT[P, A]
final case class Branch[P[_] : Functor, A](pb: P[PLPT[P, A]]) extends PLPT[P, A]

def flm[P[_]: Functor, A, B](f: A => PLPT[P, B]): PLPT[P, A] => PLPT[P, B] = {
  case Leaf(px)      => Branch(px.map(f))   // Here px.map(f) has type P[PLPT[P, B]].
  case Branch(pb)    => Branch(pb.map(t => flm(f)(t))
}
\end{lstlisting}
\[
\text{flm}^{A,B}\big(f^{:A\rightarrow P^{\text{PLPT}^{B}}}\big)\triangleq\,\begin{array}{|c||cc|}
 & P^{B} & P^{\text{PLPT}^{B}}\\
\hline P^{A} & \bbnum 0 & f^{\uparrow P}\\
P^{\text{PLPT}^{A}} & \bbnum 0 & \big(\overline{\text{flm}}\,(f)\big)^{\uparrow P}
\end{array}\quad.
\]
The code of \lstinline!flatMap! for the \lstinline!PLPT! tree never
creates any leaves, only branches. We will see later how this prevents
\lstinline!PLPT! from being a full monad (it is only a semimonad;
no \lstinline!pure! method can satisfy the required laws). Nevertheless,
having a lawful \lstinline!flatMap! is sufficient for using \lstinline!PLPT!
in functor blocks.

The following examples show some use cases for tree-like monads.

\subsubsection{Example \label{subsec:Example-monad-branching-properties}\ref{subsec:Example-monad-branching-properties}\index{solved examples}}

Implement the \lstinline!flatMap! operation for a tree of configuration
properties of the form
\begin{lstlisting}
url: http://server:8000
users:
  user:
    name: abcde
    pass: 12345
  user2:
    name: fghij
    pass: 67890
\end{lstlisting}
Write a function to convert trees into strings in this format.

\subparagraph{Solution}

The code for this data structure must support any number of simple
properties or branches with \lstinline!String! labels. A suitable
structure is a tree with $P$-shaped leaves and $P$-shaped branches,
where the functor $P$ is defined as $P^{A}\triangleq\text{List}^{\text{String}\times A}$.
Implement the tree type:
\begin{lstlisting}
sealed trait PropTree[A]  // Introduce the type parameter A for the values of properties.
final case class Simple[A](props: List[(String, A)])                  extends PropTree[A]
final case class Branches[A](branches: List[(String, PropTree[A])])   extends PropTree[A]
\end{lstlisting}
To pretty-print trees of this type, we need to keep track of the current
level of indentation:
\begin{lstlisting}
def prettyPrint[A](pt: PropTree[A], indent: String = "")(toString: A => String): String = (pt match {
  case Simple(props) => props.map { case (name, a) => indent + name + ": " + toString(a) }
  case Branches(brs) => brs.map { case (name, ps) => indent + name + ":\n" +
    prettyPrint(ps, indent + "  ")(toString) }
}).mkString("\n") + "\n"
\end{lstlisting}
For convenience, the methods \lstinline!flatMap! and \lstinline!toString!
can be defined directly on the trait,
\begin{lstlisting}
sealed trait PropTree[A] {
  def flatMap[B](f: A => PropTree[B]): PropTree[B] = this match {
    case Simple(props) => Branches(props.map { case (name, a) => (name, f(a)) })
    case Branches(brs) => Branches(brs.map { case (name, ps) => (name, ps.flatMap(f)) })
  }
  override def toString: String = prettyPrint(this)(_.toString)
}
\end{lstlisting}

The following code illustrates the \lstinline!flatMap! operation
by replacing all integer leaf values below \lstinline!100! by a simple
property and other values by a branch of properties:
\begin{lstlisting}
val pt1: PropTree[Int] = Simple(List("quantity1" -> 50, "quantity2" -> 250))

scala> println(pt1.toString)
quantity1: 50
quantity2: 250

val pt2 = pt1.flatMap { x => if (x < 100) Simple(List("value" -> x)) else Branches(List(
               "large" -> Simple(List("value" -> x / 100, "factor" -> 100)),
               "small" -> Simple(List("value" -> x % 100, "factor" -> 1))
          )) }

scala> println(pt2.toString)
quantity1:
  value: 50
quantity2:
  large:
    value: 2
    factor: 100
  small:
    value: 50
    factor: 1
\end{lstlisting}


\subsubsection{Example \label{subsec:Example-monad-substitution-language}\ref{subsec:Example-monad-substitution-language}}

Implement variable substitution for a simple arithmetic language.
Example use:
\begin{lstlisting}
val expr1: Term[String] = Const(123) * Var("a") + Const(456) * Var("b")
val expr2: Term[String] = Const(20) * Var("c")

scala> expr1.flatMap { x => if (x == "a") expr2 else Var(x) } // Substitute "a" = expr2 in expr1.
res0: Term[String] = Plus(Mult(Const(123), Mult(Const(20), Var("c"))), Mult(Const(456), Var("b"))) 
\end{lstlisting}


\subparagraph{Solution}

Begin by implementing the basic functionality of the language: constants,
variables, addition, and multiplication. The type parameter \lstinline!A!
in \lstinline!Term[A]! is the type of labels for variables. 
\begin{lstlisting}
sealed trait Term[A] {
  def +(other: Term[A]): Term[A] = Plus(this, other)
  def *(other: Term[A]): Term[A] = Mult(this, other)
  def map[B](f: A => B): Term[B] = ???
  def flatMap[B](f: A => Term[B]): Term[B] = ???
}
final case class Const[A](value: Int)                extends Term[A]
final case class Var[A](name: A)                     extends Term[A]
final case class Plus[A](t1: Term[A], t2: Term[A])   extends Term[A]
final case class Mult[A](t1: Term[A], t2: Term[A])   extends Term[A]
\end{lstlisting}
The type constructor \lstinline!Term! is an example of an abstract
syntax tree\index{abstract syntax tree} and can be equivalently defined
as
\[
\text{Term}^{A}\triangleq L^{A}+S^{\text{Term}^{A}}\quad,\quad\quad L^{A}\triangleq\text{Int}+A\quad,\quad\quad S^{B}\triangleq B\times B+B\times B\quad,
\]
where the functors $L$ and $S$ describe the structure of the leaves
and the branches of the tree.

The code of the \lstinline!map! method is
\begin{lstlisting}
  def map[B](f: A => B): Term[B] = this match { // This code must be within `trait Term[A]`.
    case Const(value)   => Const(value)
    case Var(name)      => Var(f(name))
    case Plus(t1, t2)   => Plus(t1 map f, t2 map f)
    case Mult(t1, t2)   => Mult(t1 map f, t2 map f)
  }
\end{lstlisting}
The code of \lstinline!flatMap! replaces variables by new trees,
leaving everything else unchanged:
\begin{lstlisting}
  def flatMap[B](f: A => Term[B]): Term[B] = this match { // This code must be within `trait Term[A]`.
    case Const(value)   => Const(value)
    case Var(name)      => f(name)
    case Plus(t1, t2)   => Plus(t1 flatMap f, t2 flatMap f)
    case Mult(t1, t2)   => Mult(t1 flatMap f, t2 flatMap f)
  }
\end{lstlisting}

Note that the \lstinline!flatMap! functions for lists, pass/fail
monads, and tree-like monads are information-preserving: no data is
discarded from the original tree or from any computed results.

\subsubsection{Example \label{subsec:Example-regular-shaped-tree-not-monad}\ref{subsec:Example-regular-shaped-tree-not-monad}}

Show that a regular-shaped tree \emph{cannot} have an information-preserving
\lstinline!flatMap!.\index{regular-shaped tree!is not a monad}

\subparagraph{Solution}

The type constructor $R^{A}$ for a regular-shaped binary tree is
defined by $R^{A}\triangleq A+R^{A\times A}$. We can (non-rigorously)
view the type $R^{A}$ as a disjunction with \textsf{``}infinitely many\textsf{''}
parts,
\[
R^{A}=A+A\times A+A\times A\times A\times A+...\quad,
\]
where the $n^{\text{th}}$ part ($n=1,2,...$) is a product of $2^{n}$
copies of $A$. The \lstinline!flatMap! function must have the type
\[
\text{flm}:(A\rightarrow R^{B})\rightarrow R^{A}\rightarrow R^{B}\quad.
\]
A possible value $r$ of type $R^{A}$ is, say, a product of $4$
copies of $A$. How could \lstinline!flatMap! apply to that value?
For any function $f^{:A\rightarrow R^{B}}$, we must compute a result
value $\text{flm}\,(f)(r)$ of type $R^{B}$. The only way of obtaining
a value of type $R^{B}$ is to apply $f$ to some value of type $A$.
But the given argument $r$ contains $4$ such values. If we apply
$f$ to each one of them, we will obtain $4$ different values of
type $R^{B}$. Some of these values may correspond to the part $B\times B$
in the disjunction, others to $B\times B\times B\times B$, etc. The
total number of values of type $B$ depends on the result of that
computation and is not necessarily equal to a power of $2$. Then
it will be impossible to accommodate all of those values of type $B$
within a \emph{single} regular-shaped tree of type $R^{B}$. If we
discard some values of type $B$ so that the rest fits into the regular-shaped
tree $R^{B}$, we will lose information. So, it is not possible to
implement an information-preserving \lstinline!flatMap! for a regular-shaped
binary tree. (It is not a monad.)

\subsection{The \texttt{Reader} monad\label{subsec:The-Reader-monad}}

\index{monads!Reader monad@\texttt{Reader} monad}This chapter started
with the list-like monads whose \lstinline!flatMap! method is motivated
by the requirements of nested iteration. %
\begin{comment}
We then looked at tree-like monads, which generalize nested list iterations
to tree grafting. 
\end{comment}
It turns out that the \lstinline!flatMap! method can be generalized
to many other type constructors that are useful for various programming
tasks not limited to nested iteration.

A general (semi)monad type constructor $L^{A}$ no longer represents
a collection of data items of type $A$. Instead, we regard $L^{A}$
informally as a value of type $A$ wrapped in a special \textsf{``}computational
effect\textsf{''}. We view \textsf{``}computations with an $L$-effect\textsf{''} as functions
of type $A\rightarrow L^{B}$ (as in \lstinline!flatMap!\textsf{'}s argument
type). In this view, different monads \textemdash{} such as list-like,
pass/fail, or tree-like \textemdash{} implement different kinds of
effects. An ordinary function of type $A\rightarrow B$ is a computation
with a \textsf{``}trivial effect\textsf{''}.

In this sense, monadic effects are \emph{not} side effects.\index{side effect}
Functions of type $A\rightarrow L^{B}$ can be referentially transparent\index{referential transparency}
and have value semantics\index{value semantics}. Informally, an \textsf{``}$L$-effect\textsf{''}
describes the information computed by a function of type $A\rightarrow L^{B}$
in addition to a value of type $B$. To make the vague idea of \textsf{``}effect\textsf{''}
concrete, we write the required type of the computation in the form
$A\rightarrow L^{B}$ with a specific type constructor $L$. In this
and the next subsections, we will look at some monads that can be
derived in that approach: the \lstinline!Reader!, \lstinline!Writer!,
\lstinline!Eval!, \lstinline!State!, and \lstinline!Cont! (\textsf{``}continuation\textsf{''})
monads.

The first of those, the \lstinline!Reader!, corresponds to a function
that computes a result while using some additional data of a fixed
type $Z$. A function consuming (\textsf{``}reading\textsf{''}) that additional data
will have type $A\times Z\rightarrow B$ instead of $A\rightarrow B$.
It remains to rewrite the type $A\times Z\rightarrow B$ in the form
$A\rightarrow L^{B}$ with a suitable choice of a type constructor
$L^{\bullet}$. By currying, we obtain an equivalent type
\[
(A\times Z\rightarrow B)\cong(A\rightarrow Z\rightarrow B)\quad,
\]
which has the form $A\rightarrow L^{B}$ if we define $L^{A}\triangleq Z\rightarrow A$.
This type constructor is called the \lstinline!Reader! monad\index{monads!Reader monad@\texttt{Reader} monad}
and is denoted by $\text{Read}^{Z,A}\triangleq Z\rightarrow A$. The
Scala definition is \lstinline!type Reader[Z, A] = Z => A!.

Fully parametric implementations of \lstinline!map! and \lstinline!flatMap!
directly follow from their type signatures:
\begin{lstlisting}[mathescape=true]
def map[A, B](r: Z => A)(f: A => B): (Z => B) = r andThen f  // Example $\color{dkgreen} \ref{subsec:ch-solvedExample-5}$.
def flatMap[A, B](r: Z => A)(f: A => Z => B): (Z => B) = { z => f(r(z))(z) } // Exercise $\color{dkgreen} \ref{subsec:ch-Exercise-5}$(c).
\end{lstlisting}

What are the use cases for \lstinline!Reader!? If we write a functor
block with a value of type \lstinline!Reader[Z, A]! as a \textsf{``}source\textsf{''}
value, it follows that other source values must have type \lstinline!Reader[Z, B]!,
\lstinline!Reader[Z, C]!, and so on. In other words, the type $Z$
must be fixed for the entire functor block. So, data of type $Z$
plays the role of a \emph{common dependency} that may be used by all
computations within the functor block.

As an example, imagine a program built up by composing several \textsf{``}procedures\textsf{''}.
Each \textsf{``}procedure\textsf{''} takes an argument and returns a value, like an
ordinary function, but also may need to run a Unix shell command.
For simplicity, assume that the interface to shell commands is a function
that runs a new command with given input, capturing the command\textsf{'}s
entire output. The type of that function may be $\text{String}\times\text{String}\rightarrow\text{Int}\times\text{String}$,
taking the command string and the input for the command, and returning
the command\textsf{'}s exit code and the output.
\begin{lstlisting}
type RunSh = (String, String) => (Int, String)
\end{lstlisting}
A simple implementation (that does not handle any run-time exceptions)
is
\begin{lstlisting}
import sys.process._
val runSh: RunSh = { (command, input) =>
  var result: Array[Char] = Array()
  val p: Process = command.run(new ProcessIO(
    { os => os.write(input.getBytes); os.close() },
    { is => result = scala.io.Source.fromInputStream(is).toArray; is.close() },
    _.close())
  )
  val exitCode = p.exitValue()
  (exitCode, new String(result))
}
\end{lstlisting}
We can now use this \textsf{``}shell runner\textsf{''} to execute some standard Unix
commands:
\begin{lstlisting}
scala> runSh("echo -n abcd", "") // Use `-n` to avoid trailing newlines.
res0: (Int, String) = (0, "abcd")

scala> runSh("cat", "xyz")._2   // Equivalent to `cat < $(echo -n xyz)`.
res1: String = "xyz"
\end{lstlisting}

Consider a program that determines the total line count of all files
under a given directory, but only including files whose names match
given patterns. We may split the computation into three \textsf{``}procedures\textsf{''}:
1) list all files under the given directory, 2) filter out files whose
names do not match the given patterns, 3) determine the line count
for each of the remaining files. For the purposes of this example,
we will implement each stage as a function that uses \lstinline!runSh!
to run a shell command.
\begin{lstlisting}
def listFiles(runSh: RunSh, dir: String): String = runSh(s"find $dir -type f", "")._2
def filterFiles(runSh: RunSh, files: String, patterns: String): String =
  runSh(s"grep -f $patterns", files)._2
def lineCounts(runSh: RunSh, files: String): Array[Int] = files.split("\n")   // Array of file names.
  .map { file => runSh("wc -l $file", "")._2.replaceAll("^ +", "").split(" ")(0).toInt }
\end{lstlisting}
This code assumes that file names do not contain the newline character
\lstinline!"\n"!. Use this code only as an illustration of a use
case for the \lstinline!Reader! monad.

We can now write the program like this:
\begin{lstlisting}
def getLineCount(runSh: RunSh, dir: String, patterns: String): Int = {
  val fileList = listFiles(runSh, dir)
  val filtered = filterFiles(runSh, fileList, patterns)
  val counts = lineCounts(runSh, filtered)
  counts.sum
}
\end{lstlisting}
The value \lstinline!runSh! is a common dependency of all the \textsf{``}procedures\textsf{''}
and is repeated throughout the code. This repetition becomes a problem
if we have many \textsf{``}procedures\textsf{''} within different code modules; or
when different \textsf{``}runners\textsf{''} of type \lstinline!RunSh! are used within
the program. For instance, one \textsf{``}runner\textsf{''} executes commands on a
remote machine, while another \textsf{``}runner\textsf{''} is used for testing and
returns fixed results without running any shell commands. How can
we avoid writing repetitive code and at the same time assure that
the correct \textsf{``}runners\textsf{''} are passed to all the \textsf{``}procedures\textsf{''}?

The \lstinline!Reader! monad offers a solution: it allows us to combine
smaller \textsf{``}procedures\textsf{''} into larger ones while passing the \textsf{``}runner\textsf{''}
values automatically. We first need to convert all \textsf{``}procedures\textsf{''}
into functions of type \lstinline!A => Reader[RunSh, B]! with suitable
choices of type parameters \lstinline!A!, \lstinline!B!:
\begin{lstlisting}
type Reader[Z, A] = Z => A
def listFilesR(dir: String): Reader[RunSh, String] = runSh => runSh(s"find $dir -type f", "")._2
def filterFilesR(patterns: String): String => Reader[RunSh, String] = files => runSh =>
  runSh(s"grep -f $patterns", files)._2
def lineCountsR(files: String): Reader[RunSh, Array[Int]] = runSh => files.split("\n")
  .map { file => runSh("wc -l $file", "")._2.replaceAll("^ +", "").split(" ")(0).toInt }
\end{lstlisting}
 This allows us to express \lstinline!getLineCount! as a combination
of the three \textsf{``}procedures\textsf{''} by using the \lstinline!Reader! monad\textsf{'}s
\lstinline!flatMap! function (for convenience, assume that we defined
an extension method \lstinline!flatMap!):
\begin{lstlisting}
def getLineCount(dir: String, patterns: String): Reader[RunSh, Int] = listFilesR(dir)
  .flatMap(files => filterFilesR(patterns)(files))
  .flatMap(lineCountsR).map(_.sum) // Assuming an extension method `map` is defined for `Reader`.
\end{lstlisting}
For better readability, rewrite this code equivalently in the functor
block syntax:
\begin{lstlisting}
def getLineCountR(dir: String, patterns: String): Reader[RunSh, Int] = for {
  files       <-  listFilesR(dir)
  filtered    <-  filterFilesR(patterns)(files)
  lineCounts  <-  lineCountsR(filtered)
} yield lineCounts.sum

val program: Reader[RunSh, Int] = getLineCountR(".", "patterns.txt") 
\end{lstlisting}
We obtained a value \lstinline!program! of type \lstinline!Reader[RunSh, Int]!,
which is a function type. It is important to note that at this point
no shell commands have been run yet. We merely packaged all the necessary
actions into a function value (a \textbf{monadic program}\index{monadic program}).
We now need to apply that function to a \textsf{``}runner\index{monads!runner}\textsf{''}
value of type \lstinline!RunSh!. Only then we will obtain the actual
line count:
\begin{lstlisting}
val count: Int = program(runSh)
\end{lstlisting}

The \lstinline!Reader! monad allows us to split the code into two
stages: first, we build up a monadic program (a value of type \lstinline!Reader!)
from its parts (\textsf{``}procedures\textsf{''}). Monadic programs are ordinary values
that can be passed as arguments to functions, stored in arrays, etc.
We may compose smaller monadic programs into larger ones using \lstinline!map!,
\lstinline!flatMap!, or \lstinline!for!/\lstinline!yield! blocks.
We have the full flexibility of manipulating those monadic values
and combining them into larger monadic programs in any order, since
no shell commands are being run while we perform these manipulations.
When we are done building the full monadic program, we can \textsf{``}run\textsf{''}
it using a chosen runner.\index{monads!runner}

Since the runner is the common dependency of all \lstinline!Reader!-monadic
programs, running a monadic program means performing \textbf{dependency
injection}\index{dependency injection}. At the point of running a
\lstinline!Reader! program, we have the full flexibility of choosing
the value of the dependency. The code guarantees that the dependency
will be passed correctly to each individual part of the monadic program.

\paragraph{Implicit values for dependency injection}

Scala\textsf{'}s implicit argument feature allows us to solve the problem of
dependency injection in a different way. Instead of converting all
code to use the \lstinline!Reader! monad, we convert all code to
use an implicit argument for the common dependency:
\begin{lstlisting}
def listFilesIm(dir: String)(implicit runSh: RunSh): String = ...
def filterFilesIm(patterns: String)(files: String)(implicit runSh: RunSh): String = ...
def lineCountsIm(files: String)(implicit runSh: RunSh): Array[Int] = ...

def getLineCountIm(dir: String, patterns: String)(implicit runSh: RunSh): Int = {
  val fileList = listFilesIm(dir)
  val filtered = filterFilesIm(fileList, patterns)
  val counts = lineCountsIm(filtered)
  counts.sum
}
\end{lstlisting}
Compare this code and the code that uses the \lstinline!Reader! monad:
the type signatures of functions are the same up to the \lstinline!implicit!
keyword in the last argument. Scala\textsf{'}s implicit arguments reproduce
the code style of the \lstinline!Reader! monad (especially with Scala
3\textsf{'}s implicit function types\footnote{See \texttt{\href{https://www.scala-lang.org/blog/2016/12/07/implicit-function-types.html}{https://www.scala-lang.org/blog/2016/12/07/implicit-function-types.html}}}).

\subsection{The \texttt{Writer} monad}

\index{monads!Writer monad@\texttt{Writer} monad}The \lstinline!Writer!
monad represents a function of type $A\rightarrow B$ that returns
its result (of type $B$) and additionally outputs some information
(say, logging data) about the computation just performed. Let $W$
be the type of the logging data. To model this situation, we then
need a function $f:A\rightarrow B$ and additionally a function $g:A\rightarrow W$
that computes the logging output. So, we can define the type of a
\textsf{``}computation with the \lstinline!Writer! effect\textsf{''} rigorously as
the product of the two function types,
\[
\left(A\rightarrow B\right)\times\left(A\rightarrow W\right)\cong A\rightarrow B\times W\quad.
\]
Since this type must be of the form $A\rightarrow L^{B}$, we must
define the functor $L$ as $L^{A}\triangleq A\times W$. This is the
type constructor of the \lstinline!Writer! monad, denoted by $\text{Writer}^{A,W}\triangleq A\times W$.

If several computations are performed one after another in the \lstinline!Writer!
monad, the logging information should be \textsf{``}accumulated\textsf{''} in some
way. In the logging example, additional lines are simply appended
to the log file. It means that we must be able somehow to combine
several values of type $W$ into one. A general way of doing that
is to require $W$ to be a semigroup (see Example~\ref{subsec:tc-Example-Semigroups})
with a binary operation $\oplus$. We can then implement the \lstinline!flatMap!
method for \lstinline!Writer! like this:
\begin{lstlisting}
final case class Writer[A, W: Semigroup](a: A, log: W) {
  def flatMap[B](f: A => Writer[B, W]): Writer[B, W] = {
   val Writer(b, newLog) = f(a) // Pattern-match to destructure the value f(a).
   Writer(b, log |+| newLog)    // Use the semigroup operation |+|.
}
\end{lstlisting}
\begin{comment}
\[
\text{flm}_{\text{Write}}(f^{:A\rightarrow B\times W})\triangleq a\times w\rightarrow\left(\pi_{1}f(a)\right)\times\left(w\oplus\pi_{2}f(a)\right)\quad.
\]
\end{comment}

The logging type $W$ is often a monoid (a semigroup with an \textsf{``}empty\textsf{''}
value). If so, \lstinline!Writer[A, W]! will be a full monad whose
\lstinline!pure! method is implemented as
\begin{lstlisting}
def pure[A, W: Monoid]: A => (A, W) = a => (a, Monoid[W].empty)
\end{lstlisting}
When $W$ is a semigroup but not a monoid, \lstinline!Writer[A, W]!
will be a semimonad but not a monad. 

An example of using a \lstinline!Writer! semimonad\index{semimonads!example of usage}
is logging with timestamps where we need to keep track of the earliest
and the latest timestamp. Define the type $W\triangleq~$\lstinline!Logs!
and a semigroup operation \lstinline!|+|! by
\begin{lstlisting}
final case class Logs(begin: LocalDateTime, end: LocalDateTime, message: String) {
  def |+|(other: Logs): Logs = Logs(begin, other.end, message + "\n" + other.message)
}      // For simplicity, we assume that timestamps will be monotonically increasing.
\end{lstlisting}
The type \lstinline!Logs! is not a monoid because its binary operation
discards some of the input data, so we cannot define an \textsf{``}empty\textsf{''}
value satisfying the identity laws (see Eq.~(\ref{eq:identity-laws-of-monoid})
in Example~\ref{subsec:tc-Example-Monoids}).

We can now use the semimonad \lstinline!Writer[A, Logs]!. Here are
some example computations:
\begin{lstlisting}
type Logged[A] = Writer[A, Logs]
def log[A](message: String)(x: A): Logged[A] = {        // Define this function for convenience.
  val timestamp = LocalDateTime.now
  new Logged(x, Logs(timestamp, timestamp, message))
}
def compute[A](x: => A): A = { Thread.sleep(100L); x }           // Simulate a long computation.

scala> val result: Logged[Double] = for {
  x <- log("begin with 3")(compute(3))              // The initial source type is `Logged[Int]`.
  y <- log("add 1")(compute(x + 1))
  z <- log("multiply by 2.0")(compute(y * 2.0))  // The type of result becomes `Logged[Double]`.
} yield z                                 // The computation should take between 300 and 400 ms.
res0: Logged[Double] = Writer(8.0,Logs(2020-02-15T22:02:42.313,2020-02-15T22:02:42.484,begin with 3
add 1
multiply by 2.0))
\end{lstlisting}

Unlike the \lstinline!Reader! monad, which delays all computations
until a \textsf{``}runner\textsf{''} is called, a monadic value of type \lstinline!Writer[A, W]!
already contains the final computed values of types \lstinline!A!
and \lstinline!W!.

\subsection{The \texttt{State} monad\label{subsec:The-State-monad}}

Heuristically, the \lstinline!Reader! monad $\text{Read}^{Z,A}$
is able to \textsf{``}read\textsf{''} values of type $Z$, while the \lstinline!Writer!
monad $\text{Writer}^{A,W}$ may \textsf{``}write\textsf{''} values of type $W$,
in addition to computing the result of type $A$. The \lstinline!State!
monad, denoted by $\text{State}^{S,A}$, combines the functionality
of \lstinline!Reader! and \lstinline!Writer! in a special way: the
extra value (of type $S$) is updated and automatically passed from
one computation to the next. 

To derive the required type constructor, consider a computation of
type $A\rightarrow B$ that additionally needs to read and to write
a value of type $S$. Since the total input is a pair of $A$ and
$S$, and the total output is a pair of $B$ and $S$, this kind of
computation is represented by a function of type $A\times S\rightarrow B\times S$.
We now try to rewrite this type in the form $A\rightarrow L^{B}$
with a suitable type constructor $L$. It is clear that we need to
curry the argument $A$. The result is 
\[
\left(A\times S\rightarrow B\times S\right)\cong\left(A\rightarrow S\rightarrow B\times S\right)=A\rightarrow L^{B}\quad,\quad\text{where}\quad L^{A}\triangleq S\rightarrow A\times S\quad.
\]
So, the\index{monads!State monad@\texttt{State} monad} \lstinline!State!
monad must be defined by the type constructor $\text{State}^{S,A}\triangleq S\rightarrow A\times S$.
This is a function that computes a value of type $A$ while using
and possibly updating the \textsf{``}state value\textsf{''} of type $S$.

To code of the \lstinline!flatMap! method for this type constructor
was derived in Example~\ref{subsec:ch-solvedExample-9}(c). It does
indeed pass the updated state value to the next computation:
\begin{lstlisting}
type State[S, A] = S => (A, S)
def flatMap[S, A, B](prev: State[S, A])(f: A => State[S, B]): State[S, B] = { s =>
  val (a, newState) = prev(s)   // Compute result of type `A`, updating the state.
  f(a)(newState)                // Pass the updated state to the next computation.
}
\end{lstlisting}

An example of using the \lstinline!State! monad is the task of implementing
a random number generator. A simple generator is the \textbf{Lehmer
algorithm}\index{Lehmer algorithm},\footnote{See \texttt{\href{https://en.wikipedia.org/wiki/Lehmer_random_number_generator}{https://en.wikipedia.org/wiki/Lehmer\_random\_number\_generator}}}
which generates integer sequences $x_{n}$ defined by
\[
x_{n+1}\triangleq\left(48271*x_{n}\right)\%\,(2^{31}-1)\quad,\quad\quad1\leq x_{n}\leq2^{31}-2\quad,\quad\quad n=0,1,2,...
\]
The \textsf{``}updating\textsf{''} function for this sequence, $x_{n+1}=\text{lehmer}\,(x_{n})$,
can be implemented as 
\begin{lstlisting}
def lehmer(x: Long): Long = x * 48271L % ((1L << 31) - 1)
\end{lstlisting}
In many applications, one needs uniformly distributed floating-point
numbers in the interval $\left[0,1\right]$. To produce such numbers,
let us define a helper function:
\begin{lstlisting}
def uniform(x: Long): Double = (x - 1).toDouble / ((1L << 31) - 3)   // Enforce the interval [0, 1].
\end{lstlisting}

To use the uniform generator, we need to provide an initial value
$x_{0}$ (the \textsf{``}seed\textsf{''}) and then call the function \lstinline!lehmer!
repeatedly on successive values. The code would look like this:

\begin{wrapfigure}{l}{0.4\columnwidth}%
\vspace{-0.8\baselineskip}
\begin{lstlisting}
val s0 = 123456789L  // A "seed" value.
val s1 = lehmer(s0)
val r1 = uniform(s1)
... // Use pseudo-random value r1.
val s2 = lehmer(s1)
val r2 = uniform(s2)
... // Use pseudo-random value r2.
val s3 = lehmer(s2)       // And so on.
\end{lstlisting}

\vspace{-1\baselineskip}
\end{wrapfigure}%

\noindent We need to keep track of the generator\textsf{'}s state values \lstinline!s1!,
\lstinline!s2!, ..., that are not directly needed for other computations.
This \textsf{``}bookkeeping\textsf{''} is error-prone since we might reuse a previous
generator state by mistake. The \lstinline!State! monad keeps track
of the updated state values automatically and correctly. This comes
at a cost: we need to convert all computations into \lstinline!State!-typed
monadic programs.

As a simple example, consider the task of generating uniformly distributed
floating-point numbers in the interval $\left[0,1\right]$. We need
to maintain the generator state while computing the result. The floating-point
generator is implemented as a monadic value of type \lstinline!State[Long, Double]!:
\begin{lstlisting}
val rngUniform: State[Long, Double] = { oldState =>
  val result = uniform(oldState)   // Enforce the interval [0, 1].
  val newState = lehmer(oldState)
  (result, newState)
}
\end{lstlisting}
Code using \lstinline!rngUniform! will be of the monadic type \lstinline!State[Long, A]!
for some \lstinline!A!:
\begin{lstlisting}
val program: State[Long, String] = for {  // Assume flatMap and map methods are defined for State.
  r1 <- rngUniform
  ... // Use pseudo-random value r1. The internal state of rngUniform is maintained automatically.
  r2 <- rngUniform
  ... // Use pseudo-random value r2.
} yield s"Pair is $r1, $r2" // Compute result of type String.
\end{lstlisting}

Monadic programs of this type can be composed in arbitrary ways. The
\textsf{``}bookkeeping\textsf{''} of the state values is safely handled by the \lstinline!State!
monad and hidden from the programmer\textsf{'}s view. When the entire monadic
program has been composed, it needs to be \textsf{``}run\textsf{''} to extract its
result value. Since the type \lstinline!State[S, A]! is a function
with argument of type $S$, the runner\index{monads!runner} is just
an application of that function to an initial value of type $S$,
specifying the initial state:
\begin{lstlisting}
val seed = 123456789L     // Initial state of the generator.

scala> program(seed)      // Run this monadic program.
res0: (String, Long) = ("Pair is 0.028744523433557146, 0.5269012540999576", 216621204L)
\end{lstlisting}


\subsection{The eager/lazy evaluation monad (\texttt{Eval})\label{subsec:The-eager-lazy-evaluation-monad}}

The monads \lstinline!Reader!, \lstinline!Writer!, and \lstinline!State!
manage extra information about computations. Those monads\textsf{'}
effects can be viewed as working with an extra value of a certain
fixed type. We now turn to monads whose effects are not values but
special strategies of evaluation. 

The first of these monads is called \lstinline!Eval!, and its task
is to encapsulate lazy and eager evaluations into a single type. A
value of type \lstinline!Eval[A]! can be eager (available now) or
lazy (available later). Values of these sub-types can be combined
with correct logic: for instance, a combination of eager and lazy
values automatically becomes lazy.

To derive the type constructor, note that lazy values of type $A$
are equivalent to functions of type $\bbnum 1\rightarrow A$. So,
the disjunctive type $\text{Eval}^{A}\triangleq A+\left(\bbnum 1\rightarrow A\right)$
represents a value that is either lazy or eager:\index{monads!lazy/eager evaluation monad (Eval)@lazy/eager evaluation monad (\texttt{Eval})}
\begin{lstlisting}
sealed trait Eval[A]
final case class Eager[A](x: A)              extends Eval[A]
final case class Lazy[A](lazyX: Unit => A)   extends Eval[A]
\end{lstlisting}
It is useful to have functions converting between eager and lazy values
whenever needed:
\begin{lstlisting}
def get: Eval[A] => A = {
  case Eager(x)    => x
  case Lazy(lazyX) => lazyX(())
}

def now(x: A): Eval[A] = Eager(x)
def later(e: => A): Eval[A] = Lazy(_ => e)
\end{lstlisting}
Now we can implement a \lstinline!flatMap! method that correctly
keeps track of the evaluation strategy:
\begin{lstlisting}
def flatMap[A, B](f: A => Eval[B]): Eval[A] => Eval[B] = {
  case Eager(x)    => f(x)         // This value can be eager or lazy, according to f(x).
  case Lazy(lazyX) => Lazy(_ => get(f(lazyX(()))))  // Call `get` to avoid nested Lazy().
}
\end{lstlisting}
Assuming that \lstinline!map! and \lstinline!flatMap! are defined
as extension methods for \lstinline!Eval!, we may use functor blocks
to combine eager and lazy computations freely:

\begin{wrapfigure}{l}{0.631\columnwidth}%
\vspace{-0.8\baselineskip}
\begin{lstlisting}
val result: Eval[Int] = for {
  x <- later(longComputation1()) // Delay the long computation.
  y <- now(x + 2)       // Short computation, no need to delay.
  z <- later(longComputation2(y * 100))
} yield z
\end{lstlisting}

\vspace{-1\baselineskip}
\end{wrapfigure}%

\noindent The value of \lstinline!result! is a lazy computation because
it involves lazy steps. It is quick to compute \lstinline!result!
because the long computations are not yet started. To extract the
final value of type \lstinline!Int! out of \lstinline!result!, we
need to evaluate \lstinline!get(result)!, which will take a longer
time.

\subsection{The continuation monad (\texttt{Cont})\label{subsec:The-continuation-monad}}

The continuation monad is another monadic design pattern that involves
a special evaluation strategy called the \textbf{continuation-passing}
programming style.\index{continuation-passing|textit} In that style,
functions do not return their results directly but instead call an
auxiliary function that consumes the result. The auxiliary function
is called a \textsf{``}continuation\textsf{''} or a \textsf{``}callback\index{callback}\textsf{''}.

To compare the direct style with the continuation-passing style, consider
an arithmetic calculation:
\begin{lstlisting}
def add3(x: Int): Int = x + 3
def mult4(x: Int): Int = x * 4
val result = add3(mul4(10)) // result = 43
\end{lstlisting}
Now we add callback arguments to each function and rewrite the code
as
\begin{lstlisting}
def add3(x: Int)(callback: Int => Unit): Unit = callback(x + 3)
def mult4(x: Int)(callback: Int => Unit): Unit = callback(x * 4)
def result(callback: Int => Unit): Unit = mult4(10)(r => add3(r)(callback))
\end{lstlisting}
To make the pattern more clear, replace the constant \lstinline!10!
by a function \lstinline!pure! with a callback argument:

\begin{wrapfigure}{l}{0.5\columnwidth}%
\vspace{-0.8\baselineskip}
\begin{lstlisting}
def pure(x: Int)(callback: Int => Unit): Unit =
  callback(x)

def result(callback: Int => Unit): Unit =
  pure(10) { x =>
    mult4(x) { y =>
      add3(y) { z =>
        callback(z)
      }
    }
  }
\end{lstlisting}

\vspace{-1\baselineskip}
\end{wrapfigure}%

\noindent This code is a typical pattern of continuation-passing style.
The final result of the calculation is only available as the bound
variable \lstinline!z! in a deeply nested function scope. This makes
working with this code style more difficult: All subsequent code that
needs to use the value \lstinline!z! needs to be written either directly
within that deeply nested scope, or must be contained within the given
\lstinline!callback!. This is the heuristic reason for the name \textsf{``}continuation\textsf{''}.

Another feature of the continuation-passing style is that callbacks
could be called later, while the main thread of computation continues
running concurrently. To show an example, redefine
\begin{lstlisting}
def add3(x: Int)(callback: Int => Unit): Unit = { Future(callback(x + 3)); () }
def mult4(x: Int)(callback: Int => Unit): Unit = { Future(callback(x * 4)); () }
\end{lstlisting}
The new code schedules the calls to \lstinline!callback! on separate
threads. But the type signatures of \lstinline!add3! and \lstinline!mult4!
hide this fact: they just return \lstinline!Unit!. So, the code of
\lstinline!def result(...)! remains unchanged.

The type signature of \lstinline!result! is $\left(\text{Int}\rightarrow\bbnum 1\right)\rightarrow\bbnum 1$,
which shows that it consumes a callback (of type $\text{Int}\rightarrow\bbnum 1$).
A function that consumes a callback is at liberty to call the callback
later, and to call it several times or not at all. The type $\left(\text{Int}\rightarrow\bbnum 1\right)\rightarrow\bbnum 1$
does not show whether the callback will be called; it merely \textsf{``}registers\textsf{''}
the callback for possible later use. This gives us flexibility in
the execution strategy, at the cost of making the code more complicated
to write and to understand.

One complication is that it is difficult to maintain code that contains
deeply nested function scopes. The continuation monad solves this
problem by converting nested function scopes into more easily composable
functor blocks. The code also becomes more readable.

To derive the required type constructor, consider a computation of
type $A\rightarrow B$ that needs to use the continuation-passing
style. Instead of returning a value of type $B$, it registers a callback
function for possible later use and returns a \lstinline!Unit! value.
If the callback has type $B\rightarrow\bbnum 1$, the total input
of our computation is $A\times\left(B\rightarrow\bbnum 1\right)$
while the output is simply $\bbnum 1$. So, the type of a continuation-passing
computation is $A\times\left(B\rightarrow\bbnum 1\right)\rightarrow\bbnum 1$.
Rewrite this type in the form $A\rightarrow L^{B}$ with a suitable
functor $L$:
\[
\left(A\times\left(B\rightarrow\bbnum 1\right)\rightarrow\bbnum 1\right)\cong\left(A\rightarrow\left(B\rightarrow\bbnum 1\right)\rightarrow\bbnum 1\right)=A\rightarrow L^{B}\quad,\quad\text{where}\quad L^{A}\triangleq\left(A\rightarrow\bbnum 1\right)\rightarrow\bbnum 1\quad.
\]
It is sometimes helpful if the callback returns a more informative
value than \lstinline!Unit!. For instance, that value could show
error information or give access to processes that were scheduled
concurrently.

So, we generalize the type constructor $L$ to $\left(A\rightarrow R\right)\rightarrow R$,
where $R$ is a fixed \textsf{``}result\textsf{''} type. This type constructor is
called the \textbf{continuation monad}\index{monads!continuation monad (Cont)@continuation monad (\texttt{Cont})}
and is denoted by $\text{Cont}^{R,A}\triangleq\left(A\rightarrow R\right)\rightarrow R$.

How does the continuation monad make callback-based code composable?
The answer is in the code of the \lstinline!flatMap! method. Its
implementation is (Exercise~\ref{subsec:ch-Exercise-7})
\begin{lstlisting}
type Cont[R, A] = (A => R) => R
def flatMap[R, A, B](ca: Cont[R, A])(f: A => Cont[R, B]): Cont[R, B] = { br => ca(a => f(a)(br)) }
\end{lstlisting}
The code of \lstinline!flatMap! substitutes a new callback, \lstinline!br: B => R!,
into the innermost scope of the computation \lstinline!f!. In this
way, we obtain easy access to the innermost callback scope. This trick
makes code with deeply nested callbacks composable.

After defining \lstinline!map! and \lstinline!flatMap! as extension
methods on \lstinline!Cont!, we can rewrite the code above as
\begin{lstlisting}
def pure[A]: A => Cont[Unit, A] = a => ar => ar(a)
def add3(x: Int): Cont[Unit, Int] = callback => callback(x + 3)
def mult4(x: Int): Cont[Unit, Int] = callback => callback(x * 4)

val result: Cont[Unit, Int] = for {
  x <- pure(10)
  y <- mult4(x)
  z <- add3(y)
} yield z
\end{lstlisting}
This style of code is more readable and easier to modify.

The result of the computation has type $\text{Cont}^{\bbnum 1,\text{Int}}$
(so, it is a function). Like the \lstinline!State! and the \lstinline!Reader!
monads, the continuation monad delays all computations until we apply
a runner.\index{monads!runner} One way of extracting values from
\lstinline!Cont!-monadic programs is to use a runner producing a
\lstinline!Future! value that resolves when the callback is called:

\begin{wrapfigure}{l}{0.515\columnwidth}%
\vspace{-0.8\baselineskip}
\begin{lstlisting}
def runner[A](c: Cont[Unit, A]): Future[A] = {
  val pr = Promise[A]() // scala.concurrent.Promise
  c { a => pr.success(a) }  // Resolve the promise.
  pr.future        // Create a Future from Promise.
}
// Wait for the Future value.
Await.result(runner(result), Duration.Inf)
\end{lstlisting}

\vspace{-1\baselineskip}
\end{wrapfigure}%

\noindent This runner uses special low-level features of the \lstinline!Future!
class, such as a mutable value of type \lstinline!Promise!. If these
features are used in many places in the code, the programmer runs
the risk of creating concurrency bugs, such as race conditions or
deadlocks, that are difficult to fix. When using the continuation
monad, typically there will be only one place in the code where a
monadic program is being \textsf{``}run\textsf{''}. In this way, we isolate the high-level
business logic in the \lstinline!Cont! monad from the low-level code
of the runners.

We conclude this subsection with some more examples of using the continuation
monad.

\subsubsection{Example \label{subsec:Example-continuation-monad-computation-cost}\ref{subsec:Example-continuation-monad-computation-cost}\index{solved examples}}

Each arithmetic computation (such as \lstinline!add3! or \lstinline!mult4!)
has a certain arbitrarily specified cost (of a monoid type $W$).
Use the monad \lstinline!Cont[W, A]! to implement computations with
specified cost. The total cost must automatically add up when computations
are chained using \lstinline!flatMap!.

\subparagraph{Solution}

The functions \lstinline!pure!, \lstinline!add3!, and \lstinline!mult4!
need to be redefined with new types:
\begin{lstlisting}
implicit val monoidW: Monoid[W] = ???  // Implement the "cost" monoid here.
def pure[A](a: A): Cont[W, A] = { ar => ar(a) }
def add3(x: Int, cost: W): Cont[W, Int] = { callback => callback(x + 3) |+| cost }
def mult4(x: Int, cost: W): Cont[W, Int] = { callback => callback(x * 4) |+| cost }
\end{lstlisting}
The computation of \lstinline!result! can be now written as
\begin{lstlisting}
val result: Cont[W, Int] = for {
  x <- pure(10)
  y <- mult4(x, cost1) // Here, cost1 and cost2 are some values of type W.
  z <- add3(y, cost2)
} yield z
\end{lstlisting}
The implementation of \lstinline!runner! now needs to take an initial
cost value. We can generalize the previous code of the runner to an
arbitrary result type $R$:
\begin{lstlisting}
def runCont[R, A](c: Cont[R, A], init: R): (R, Future[A]) = {
  val promise = Promise[A]()
  val res = c {a => promise.success(a); init}    // Resolve the promise and return init.
  (res, promise.future)      // Return the new result value r together with a Future[A].
}
val (totalCost, futureResult) = runCont(result, Monoid[W].empty)
val resultInt = Await.result(futureResult, Duration.Inf)   // Wait for the Future value.
\end{lstlisting}

If the code contains many other monadic operations such as \lstinline!add3!
and \lstinline!mult4!, it is inconvenient to hard-code the cost each
time. Instead, we can easily implement a function that adds a given
cost to any given monadic operation:
\begin{lstlisting}
def addCost[A](c: Cont[W, A], cost: W): Cont[W, A] = { callback => c(callback) |+| cost }
\end{lstlisting}


\subsubsection{Example \label{subsec:Example-continuation-monad-java-api}\ref{subsec:Example-continuation-monad-java-api}}

Convert the callback-based API of \lstinline!java.nio! to the continuation
monad. Read a file into a string, write that string to another file,
and finally read the new file again to verify that the string was
written correctly. Do not implement any error handling.

\subparagraph{Solution}

The\lstinline! java.nio! package provides APIs for asynchronous input/output
using buffers. For instance, the code for reading a file into a string
works by creating a \lstinline!fileChannel! and then calling \lstinline!fileChannel.read!
with a callback (encapsulated by the \lstinline!CompletionHandler!
class). The result of reading the file is available only when the
callback is called, and only within the callback\textsf{'}s scope:
\begin{lstlisting}
import java.nio.ByteBuffer
import java.nio.channels.{AsynchronousFileChannel, CompletionHandler}
import java.nio.file.{Paths, StandardOpenOption => SOO}

val fileChannel = AsynchronousFileChannel.open(Paths.get("sample.txt"), SOO.READ)
val buffer = ByteBuffer.allocate(256)// In our simple example, the file is shorter than 256 bytes.

fileChannel.read(buffer, 0, null, new CompletionHandler[Integer, Object] {
  override def failed(e: Throwable, attachment: Object): Unit = println(s"Error reading file: $e")
  override def completed(byteCount: Integer, attachment: Object): Unit = {
    println(s"Read $byteCount bytes")
    fileChannel.close()
    buffer.rewind()
    buffer.limit(byteCount)
    val data = new String(buffer.array()) // Within this scope, we can work with the obtained data.
  }
}
\end{lstlisting}
Writing data to file is implemented similarly:
\begin{lstlisting}
val outputFileChannel = AsynchronousFileChannel.open(Paths.get("sample2.txt"), SOO.CREATE, SOO.WRITE)
outputFileChannel.write(buffer, 0, null, new CompletionHandler[Integer, Object] {
  override def failed(e: Throwable, attachment: Object): Unit = println(s"Error writing file: $e")
  override def completed(byteCount: Integer, attachment: Object): Unit = {
    println(s"Wrote $byteCount bytes")
    outputFileChannel.close()
    ... // Continue the program within the scope of this callback.
  }
}
\end{lstlisting}
This API forces us to write the business logic of the program in deeply
nested callbacks, since the results of input/output operations are
only available within the callback scopes. The continuation monad
solves this problem by converting all values into the function type
\lstinline!Cont[Unit, A]!. Begin by defining monadic-valued functions
that encapsulate the \lstinline!java.nio! APIs for reading and writing
files:
\begin{lstlisting}
type NioMonad[A] = Cont[Unit, A]
def nioRead(filename: String): NioMonad[ByteBuffer] = { callback =>
  val buffer = ByteBuffer.allocate(256)
  val channel = AsynchronousFileChannel.open(Paths.get(filename), SOO.READ)
  channel.read(buffer, 0, null, new CompletionHandler[Integer, Object] {
    override def failed(e: Throwable, attachment: Object): Unit = println(s"Error reading file: $e")
    override def completed(result: Integer, attachment: Object): Unit = {
      buffer.rewind()
      buffer.limit(result)
      channel.close()
      callback(buffer))
    }
  })
}
def nioWrite(buffer: ByteBuffer, filename: String): NioMonad[Int] = { callback =>
  val channel = AsynchronousFileChannel.open(Paths.get(filename), SOO.CREATE, SOO.WRITE) 
  channel.write(buffer, 0, null, new CompletionHandler[Integer, Object] {
    override def failed(e: Throwable, attachment: Object): Unit = println(s"Error writing file: $e")
    override def completed(result: Integer, attachment: Object): Unit = {
      channel.close()
      callback(result.intValue)
    }
  })
}
\end{lstlisting}
Using these functions, we can implement the required code using a
functor block in the \lstinline!Cont! monad:
\begin{lstlisting}
val filesHaveEqualContent: NioMonad[Boolean] = for {
  buffer1 <- nioRead("sample.txt")
  _       <- nioWrite("sample2.txt")
  buffer2 <- nioRead("sample2.txt")
} yield { new String(buffer1.array()) == new String(buffer2.array()) }
\end{lstlisting}
The code has become significantly easier to work with, as its high-level
logic is clearly displayed.

Since the input/output operations are run concurrently, the value
of type \lstinline!NioMonad[Boolean]! is a function that will compute
its \lstinline!Boolean! result at some time in the future. We can
use the runner shown above to wait for that value to become available:
\begin{lstlisting}
val result: Future[Boolean] = runner(filesHaveEqualContent)

scala> Await.result(result, Duration.Inf)
res0: Boolean = true
\end{lstlisting}


\subsection{Exercises\index{exercises}}

\subsubsection{Exercise \label{subsec:Exercise-monads-p1}\ref{subsec:Exercise-monads-p1}}

For a given set of type \lstinline!Set[Int]!, compute all subsets
$\left(w,x,y,z\right)$ of size 4 such that $w<x<y<z$ and $w+z=x+y$.
(The values $w$, $x$, $y$, $z$ must be all different.)

\subsubsection{Exercise \label{subsec:Exercise-monads-p1-1}\ref{subsec:Exercise-monads-p1-1}}

Given 3 sequences $xs$, $ys$, $zs$ of type \lstinline!Seq[Int]!,
compute all tuples $\left(x,y,z\right)$ such that $x\in xs$, $y\in ys$,
$z\in zs$ and $x<y<z$ and $x+y+z<10$.

\subsubsection{Exercise \label{subsec:Exercise-monads-p1-2}\ref{subsec:Exercise-monads-p1-2}{*}}

Solve the $n$-queens problem on an $3\times3\times3$ cube.

\subsubsection{Exercise \label{subsec:Exercise-monads-p1-4}\ref{subsec:Exercise-monads-p1-4}}

Read a file into a string and write it to another file using Java
\lstinline!Files! and \lstinline!Paths! API. Use \lstinline!Try!
and \lstinline!for!/\lstinline!yield! to make that API composable
and safe with respect to exceptions.

\subsubsection{Exercise \label{subsec:Exercise-monads-p1-3}\ref{subsec:Exercise-monads-p1-3}}

Write a tiny library for arithmetic using \lstinline!Future!s, implementing
the functions:
\begin{lstlisting}
def const(implicit ec: ExecutionContext): Int => Future[Int] = ???
def add(x: Int)(implicit ec: ExecutionContext): Int => Future[Int] = ???
def isEqual(x: Int)(implicit ec: ExecutionContext): Int => Future[Boolean] = ??? 
\end{lstlisting}
Use these functions to write a functor block (\lstinline!for!/\lstinline!yield!)
program that computes $1+2+...+100$ via a parallel computation and
verifies that the result is correct.

\subsubsection{Exercise \label{subsec:Exercise-monads-p1-5}\ref{subsec:Exercise-monads-p1-5}}

Given a semigroup $W$, make a semimonad out of the functor $F^{A}\triangleq E\rightarrow A\times W$.

\subsubsection{Exercise \label{subsec:Exercise-monads-p1-6}\ref{subsec:Exercise-monads-p1-6}}

Implement \lstinline!map! and \lstinline!flatMap! for the tree-like
functor $F^{A}\triangleq A+A\times A+F^{A}+F^{A}\times F^{A}$.

\subsubsection{Exercise \label{subsec:Exercise-monads-p1-7}\ref{subsec:Exercise-monads-p1-7}{*}}

Find the largest prime number below $1000$ via a simple sieve of
Eratosthenes.\footnote{See \texttt{\href{https://en.wikipedia.org/wiki/Sieve_of_Eratosthenes}{https://en.wikipedia.org/wiki/Sieve\_of\_Eratosthenes}}}
Use the \lstinline!State[S, Int]! monad with \lstinline!S = Array[Boolean]!.

\begin{comment}
in this part of the tutorial I will talk about Mona\textsf{'}s and semi Mona\textsf{'}s
this continues a consideration of how we can do computations in a
functor context or in Scala this is the functional block for the for
yield block in this part I will concentrate on practical issues the
first example we will use is this computation in this computation
we need nested iterations in the factor block nested iterations are
expressed with several left arrows or they're called generator arrows
so the program for this computation can look like this from the left
I show it in the filter block syntax on each line as you see the generator
line gives you an iteration I goes over this sequence from 1 to M
J also goes over the same sequence and K those over the same sequence
and they all go independently so I for each I and J goes over all
these and for each I and J K goes over all of this and in the yield
expression we compute this function f that we're supposed to compute
here and the result of this sub expression up to this parenthesis
is a large list of all values of F for each choice of I J and K and
then we take a sum of this large list so that computes the sum in
this expression if you replace the left arrows as the Scala compiler
does through map and flatmap and you will see that the map replaces
the last left arrow and flatmap replaces all other flap left arrows
or generator errors and so line for line translation of this code
could look like this so instead of this syntax we have this instead
of this we have this and so on and you see how this works so the last
expression is just a simple map because we just need to compute the
value F for each of these case but this result is a list and soldered
argument a flat map is a function that takes J and returns a list
the result of the flat map is again a list which is this one up to
this brace and this is the body of this function taking I as the argument
and returning this list so again the argument of flat map as a function
from a value to a list so this syntax is available for the sequence
factor because sequence has flat map defined in addition to map if
that function has a filter defined where the function method is called
with filter as we have seen in the previous tutorial then we can use
the if lines in the function block as well in this tutorial we will
occasionally see the if lines but we'll concentrate on what happens
when you have several left arrows it is named flat map because it
is actually equivalent to us first doing a map and then doing a flattened
how would that work well in this this code were the function in the
brackets or in the parentheses here takes J and returns a list the
result of that would be a list of Lists and when you flatten that
you get a simple list and that is the same as doing a flat map so
factors that have flat map or and flatten defining them I call them
platinum or semi monads this is my own terminology flattened able
and semi mu nuts is my terminology there is no accepted name for these
factors you must have heard of monent now monads are more than just
founders at her flat map or flattened monads also needed an additional
method called pure which has this type signature however this method
cannot be used in the function block directly so it does not correspond
to a specific construction of a functor block of course let me correct
myself it can be used in the function block as any other method but
it has to be used here on the right-hand side because here this an
arbitrary Scala code here so you can use any methods you want but
it is not special to the function block it does not have a special
meaning and also we will not need this method much in fact it is not
not very often used other methods are more important than pure and
so mathematically and adding the meta pure makes an interesting mathematical
structure but for the practical use that I'm going to talk about this
is not very important so full monitor monads are factors that have
flatmap and pure with appropriate laws which I will talk about in
another part of this tutorials semi monads are those that just have
flat map and they may or may not have pure in many cases they will
also have some natural definition of pure but in some cases they won't
so let\textsf{'}s concentrate therefore one semi Mona\textsf{'}s monads that don't have
pure necessarily let\textsf{'}s look at more a visual example of how a flat
map works with lists so consider this expression how we would compute
that expression so let\textsf{'}s assume that the function f takes a value
of x and returns a list of some values of type y now if you have specific
values x1 x2 x3 here then the result of applying F to them might be
a different list each time it could be even a list of different lengths
with different values inside so let\textsf{'}s imagine this is the result of
applying f2 x1 x2 and x3 so the flat map will put all of these values
together in one list we first do melt and then we do flatten and what
happens is that the map will replace each of these x ones with its
corresponding list x1 x2 x3 will be replaced by these three lists
so that would be a list of lists of Y and you flatten that and you
get a simple or flat list let\textsf{'}s develop some more intuition about
what happens with data in a factory or in a collection or in a container
when we use flatmap or when we use several generator errors in the
factor block so here is a schematic example of some code that tells
you that I goes over this collection or container or sequence in this
case J goes over here then we compute some X as a function of I J
now at this point we have computed a whole sequence of X\textsf{'}s for each
I and J different experts then we for each of those X\textsf{'}s we still have
another it nested iteration and then we compute some Y as a function
of I J and K and actually at this point we have computed a large list
of Y\textsf{'}s of perhaps different values of Y different for each I J and
K and then we compute another function H of x and y so this entire
result will be a long list of values of this H computed for each high
J and K a different value of H so this code is a translation into
non hunkler block syntax so you see line 4 line same thing 1 to M
1 to M I I 1 to N 1 to N J J so this is here x equals this here we
need to say well in the function block we don't say well that\textsf{'}s the
only syntactic difference so 1 2 P 1 2 P ok ok so here we having this
line by line translation this code computes exactly the same value
of the result which is going to be a list of so one thing we notice
is that every line that is a generative line that is every line it
has a left arrow must have the same type of container on the right
hand side so this is a list or sequence in general in this case this
is going to be subclasses of sequence some vector or something like
that each generator line needs to have the same type we could not
for example here use sequence and here use some completely different
containers such as let\textsf{'}s say tree or some point that we couldn't do
this must be the same type and this is so because flatmap is defined
like this flat map requires that this sequence type is the same as
the sequence type returned by this function which is all of that so
all of that should be a sequence of the same type as this and so for
this reason each container or sequencer or collection on the right
hand side of a generator arrow must have the same type same container
type another thing we know is that each generator line actually starts
an expression so if you look at this generator line for example DJ
the translation of this actually is this J goes to that so this entire
thing is a an expression that evaluates to to a list to a sequence
which is again a container of the same type so you can think about
this syntax as nested computation where each line starts in new computation
yielding finally the value of the same type let\textsf{'}s now look also at
the number of resulting data items now I goes from 1 to N J goes from
1 to N K goes from 1 to P so in this case clearly we have M times
n times P different elements in the resulting list here so this will
be M times n times P values in the result if we had some other code
here for example if this were not from 1 to n always but the length
of this sequence were somehow a function of this value 1 I let\textsf{'}s say
now we would probably have the different number of data items depending
on the data or we could have fewer data items because we could have
an if line which would filter out some of the data so we'll have less
than M times n times P but in any case we could have up to M times
n times P resulting data items in their container so the container
type that we need for this kind of computation is at least such that
it can hold m times n times P items if it can hold em items for n
items for p- so if we ask the question what kind of containers can
have flatmap in other words what kind of containers will fit this
style of computation the answer is at least this type of containers
must be such that if the container can hold em items of data and it
can hold end items of data it must also be able to hold at least m
times n items of data so the capacity of the container must be closed
under multiplication always the set of all possible capacities or
capacity counts of the container must be closed under multiplication
this is an interesting property with container types have this property
so for instance a sequence or a non-empty list these containers can
hold any number of items in the case of non-empty lists any number
of items that\textsf{'}s at least one so that set is a set of all integers
at at least some minimum that set is certainly closed under multiplication
and also well it\textsf{'}s not just multiplication must be closed under this
it must be if it has m elements and it has n elements it should be
able to hold all less than M times n elements any number of pretty
much elements less than that so obviously sequence and non-empty lists
are such containers with this property another important example of
such containers is the container that can hold only 0 or 1 elements
for example option is such a container option can hold one data port
it could be empty either is another container data item have some
error message thing try is another such container it could have a
date I could have an exception future is another such container it
holds the data item that is going to be available in the future or
it could fail also the computer so these I call the pass fail containers
these could hold at most one data item and clearly the set of capacities
for this container is a set of 2 L two numbers 0 and 1 and this set
is closed under multiplication another example of a container that
would have this property is a tree light container that must have
for instance three six nine twelve and so on elements that are always
multiples of three let\textsf{'}s say yeah so it\textsf{'}s bit branches in such a way
that it can always hold can only hold the number of items that\textsf{'}s multiplied
that smell a multiple of three and obviously this kind of set is closed
under multiplication finally there are several containers that I will
also talk about which are which I call non-standard examples of such
containers are these so these are functors because here a is a covariant
position here also a is in a covariant position because it\textsf{'}s behind
two arrows two functionaries so these are factors but they are not
really containers with data in an ordinary sense there\textsf{'}s no way in
which you can say they hold five or eleven items of data or something
like this they hold data in some non-standard way and we will talk
about the usage of these containers and give examples but these also
in certain cases certain function types like these also can have flat
map defined on them in a reasonable way so let\textsf{'}s look at examples
now the first set of examples are what I call a list like monads so
by the way all these examples here are monads are not just semi Munez
but we will just look at the flat map and so we will not use the fact
that there are full moon ads so for us it\textsf{'}s not really important to
make that distinction right now we only focus on flat map so what
are the typical tasks that list like monads before typical is make
a list of combinations or permutations to go over these filter out
what you want and get a list of results that\textsf{'}s a typical computation
of this kind another situation is that if you have some problem that
has many possible solutions you organize these solutions in a solution
tree and you traverse this tree with say a recursive depth first search
and then you again filter out solutions that are incorrect and you
get your resulting solutions now the containers that have this property
it may be eager sequence so eager means all elements of the sequence
are computed upfront before you can use the sequence for they can
be lazy which also iterator is one example is a sequence whose elements
are not all computed upfront you can already start using the iterator
and as you need it will compute new elements so that\textsf{'}s called lazy
computation stream is another the data type in the Scala standard
library that computes lazy value so it does not compute upfront all
the values in the stream computes them when you need to do so once
you have confused them they are stored in memory but until then they
are not so these are eager and lazy evaluation strategies but the
way your write code is very similar you just have flat map defined
on iterator you have flat map defined on stream and so you can just
use them usually list like containers have a lot of additional methods
defined in them it\textsf{'}s a very rich data structure so they're monads
they have pure metal defining them I just remind you that the pure
method has this type so it just takes one data item and creates a
container that has this one little item inside so clearly you can
put one item in the list or an iterator on the stream and so on comes
clear but many additional methods are used such as appending lists
pretending elements to list concatenating lists fill so you make a
list that has certain pre computed elements fold scan those are methods
are you are all defined on this list like Mona\textsf{'}s so actually program
code mostly uses methods like these and not pure so it is not very
important for programming for the practice of programming to have
the method viewer defined list like Mona and actually it\textsf{'}s the same
for most moments the method pure is quite secondary in its importance
for practical programming so let\textsf{'}s look at some example so I have
prepared working code in the repository so let\textsf{'}s take a look so here
is the first example how we compute things in the function block what
we want is to compute a {[}Music{]} multiplication table so the results
should be a sequence of strings such as these so these strings need
to be computed in this order so notice that the multiplication table
is only half of the matrix its we never compute for example three
times two we already have two times three and sufficient and so to
organize this kind of computation we write this so I goes from 1 to
5 but J goes from I to 5 so this is an example of the collection on
in the right hand side of the generator line and the collection is
a function of the value that we defined in the previous line so this
collection is a function of I so this is a example of having a different
list you know each time for each I will be a different list and that\textsf{'}s
fine this is just as easy to do that using the function lock with
mu naught so what do we yield in other words for each I and for each
J what do we compute or we compute the product of I and J and then
we print this line I times J equals product so that will produce a
string and the whole result will be a sequence of these strings so
we have a flat sequence so to speak remember this heuristic or a mnemonic
choice of word of the name flat map so we we have many nested iterations
here when the result is a flat sequence so this test verifies that
the result is this multiplication table here is how we can do the
same using a filter so here we do not make this second sequence depending
on their both same but then we filter out by the condition that J
must be not less than I so then we we can compute product here that\textsf{'}s
completely equivalent in terms of results and we yield this listener
perhaps slightly different and maybe easier to understand way of doing
the same thing so it still computes the same multiplication table
as we had here I already ran all these tests they all pass so you
I encourage you to download this and run as well and play with it
to save time I will not run tests but they all pass another important
thing here is to notice that if one of the generator arrows returns
you an empty sequence then remember this size of the result is a product
of sizes of these sequences and the sequences of length zero and so
the resulting sequence will be of length zero it will be empty so
just having one of these generators produce an empty sequence will
kill the entire computation it will make an empty sequence out of
the entire computation regardless of what you do here before or after
it will just completely collapse everything into an empty sequence
that is also an important property of the magnetic computation so
let\textsf{'}s now go through our worked examples in that slide the first example
is to compute all permutations of the sequence of three strings a
B and C so how do we compute that let\textsf{'}s just write code like this
so first we define the sequence excess or excess now obviously we
need to iterate over it in some way to get the permutation so let\textsf{'}s
do that so let\textsf{'}s say X goes over all this now once X let\textsf{'}s say is
a we need to go over the result over the remaining elements so let\textsf{'}s
compute the remaining elements here so diff is the library function
that computes the difference between two sequences or it removes elements
from the second elements that are in the second sequence are removed
from the first sequence when you do div and so the remain will be
BC for instance if X is a then we go over the remain and we find and
next remain so remain tube which is now all the rest and Z goes over
remain two so now we know that it\textsf{'}s a sequence of three elements so
we know that remain two is going to have just one element left so
that\textsf{'}s what we want and the result is we yield the sequence of XYZ
and so this is going to be computed for each choice of XY and Z so
the result will be a sequence of sequences so let\textsf{'}s check that control
shift right so that\textsf{'}s a sequence of sequence of string that\textsf{'}s the
result we check on this test that the permutations are correctly computed
the standard library in Scala already has the permutations function
just that the permutations function returns an iterator not a sequence
so we converted to see in order to run this test if we didn't convert
it to sequence and we couldn't compare our sequence of sequences against
an iterator the iterator doesn't have the values computed yet cannot
compare something that already has all the values computed and something
that doesn't we need to run that to them to compute all the values
so that\textsf{'}s what the two sequence does for me it\textsf{'}s very careful the
second example is to compute all subsets of this set now subsets of
the set is not the same at all as permutations of a sequence for instance
empty set would be a subset or a set of B alone would be a subset
or a set of B and C would be a subset but there is no difference between
the set of B and C and a set of C and B so all subsets is very different
from all permutations let\textsf{'}s see how we can do that so let\textsf{'}s think
about it so first the subsets could be empty so we need to allow empty
set the subsets can be also non empty so let\textsf{'}s allow that as well
so we we say X a would be of type set of string and so X a would go
over either an empty set or a set of a so in this generator line the
right-hand side is a collection or our in this case it is a set and
the set contains two elements an empty set of strings and a set of
single-a so exhale be  empty set or set of a xB would be similarly
either an empty set or set of B XC will be in either in the second
set of C and then we will concatenate all these sets now when we concatenate
sets equal sets would collapse into one and so the result would be
empty set will be present once then we'll be set of a together maybe
with empty or together a set of B so in this way we have eight combinations
that we need so either each of the X a xB XC goes over to possible
values and so the result is 8 X or two times two times two different
sets so indeed we have a standard library function subsets that returns
an iterator we convert that iterator to set and the result is correct
so it\textsf{'}s all subsets of this next example is to compute all sub sequences
of length 3 out of a given sequence so sub sequences are not necessarily
elements or they're next to each other in sequence but they must be
in the water so let\textsf{'}s look how we can do this so here\textsf{'}s an example
we have a sequence from 1 to 5 and the sub sequences of length 3 out
of this are listed here so it\textsf{'}s one two three one two four one two
five one three four and so on so how do we compute such a sub sequence
well we start reasoning by what kind of generator lines we should
write and what kind of filtering we should do that\textsf{'}s the way that
this kind of code is written we use the library function tails which
is a useful function saves us work what does it do it takes a sequence
and it computes a sequence of first initial one then the tail of the
sequence have a tail of the tail and the tail of that and so on until
we get an empty sequence so XS is going to be a sequence of these
ranges we filter out the new and then we know then it\textsf{'}s that it\textsf{'}s
not empty actually we filter out not the new we filter out the case
when this entire tails is empty because it could happen what if we're
given an empty sequence here then this entire tails sequence will
be empty so we filter out non-empty we take the head and that\textsf{'}s the
first sequence here and then we take the tail of that which so the
tail of excess is these and that\textsf{'}s our remain one so now we go over
the sequences in these and in the tail of XS so if let\textsf{'}s say first
of all would be DS again we filter out as its it must be non-empty
take the head and then take the tail of that and this what this does
is that in the next iteration we would have x1 here why being here
for example and so that\textsf{'}s how we find all the possible sub sequences
so we can take this this and this and taking heads of those would
give us 1 3 4 4 1 3 5 and so on so this is the way we induce the sub
sequences this is a bit manual there\textsf{'}s a lot of boilerplate code but
this is a code that kind of is obvious obviously correct we take details
then other tails and so on and it works as expected so you see we
have used if we have used non generator lines or the computation lines
which are map these are flat map this is a filter so we use all the
features of the list as we should we should always use all the features
if they are helpful so this code computes the sequences we expect
the next task is to generalize all these examples to support arbitrary
length instead of three so here we had hard-coded length in hard-coded
length 3 now we want to generalize and this is of course a little
more challenging but notice in all these code examples we had really
hard-coded the fact that we are looking at length 3 let\textsf{'}s see how
we can generalize this it\textsf{'}s not a lot of work it\textsf{'}s just needs to be
a little more clever so let\textsf{'}s look at the first example the first
example is permutations well obviously we still do the same thing
as before let\textsf{'}s take our code for permutations see what we do so we
we do X going through the sequence then we compute the remain the
remaining subsequence or part of the sequence by removing the X we
just chose so the result is a smaller subsequence and let\textsf{'}s just use
the same function to compute the permutations of that recursively
so that\textsf{'}s the idea here so we take X going to it over over all the
XS compute the remain and then the Y\textsf{'}s is going to go over all the
permutations of remain and that is a recursive call to the same function
so Y is going to be a sequence of elements because the function returns
a sequence of sequence so since on the right hand side of the generating
line we here have a sequence of sequences the left-hand side will
become a sequence now notice the generator light has to be the same
container type sequence doesn't have to be the same element type so
in the first generator line the container type is sequence the element
type is a and here the container type is sequence the element type
is sequence of a so that\textsf{'}s fine as long as the outer container type
stays the same now this variable is going to be sequence of a so we
need to append X which is the first element which shows and the permutations
of the other elements so the result is that we yield at this sequence
and the total result is going to be Kwan\textsf{'}s of these sequences for
all X\textsf{'}s and for all permutations on the remainder and that\textsf{'}s what
we need except you have to add this check at the very beginning because
we will eventually call the permutations on an empty sequence here
and we need to not break when we when we have that so that\textsf{'}s how it
works and now we can have any length and it works so let\textsf{'}s see how
example 2 is generalized we look at the code and example 2 we see
we need to basically repeat this n times we repeated this line three
times here but now we need to repeat this n times instead of three
times so how do we do that we use recursion of course so the first
line we can continue and as before then we do the remain which is
also the - here is the operation defined on set that removes elements
from a set well it\textsf{'}s not it doesn't really modify this set it\textsf{'}s just
compute a new set that has one element viewer possibly then we do
the recursive call of subsets on the remain and gives us a bunch of
sets so for each of those sets we have a wide age and we concatenate
the sets so it\textsf{'}s very similar thank very similar idea so we we do
one step that we did before and then we call the cursor away on the
remainder and that works for any length of the set example 3 is a
bit more ago but that\textsf{'}s exactly the same procedure in example three
we had this kind of code repeated three times ex going to seek on
something tails if non-empty get the head and compute the remained
take the tails if not everything at the head compute tail yet tails
of non empty so that is going to be repeated so we're going to write
this once and then do the recursive call so that\textsf{'}s how this works
in generalizing our example three so again we need to check for empty
sequences and that\textsf{'}s a little involved I won't go into details here
encourage you to look at it yourself the main computation is here
notice I have to put parentheses around the four because I needed
to seek on it and you cannot just do it to seek after this brace that
is not right syntax this brace is part of the yield expression and
so if you wanted to seek on the entire it\textsf{'}s for yield block you have
to put parentheses around it alright so this is our code that we have
to do go to tails non-empty get head and find remainder and then we
do a recursive call now notice recursive call is on n minus one because
now the task is the compute n element sub sequences of a given sequence
now we compute n minus 1 element sub sequences and sometimes this
n would be 0 sometimes the remain will be empty so we need to check
both of these cases separately so that\textsf{'}s how it works exactly the
same test passes next example is the well-known 8 Queens problem 8
Queens is a chess Queens on the chess board and you need to find all
locations for the 8 Queens so that they don't threaten each other
the Queens on the chess board threaten each other if they're in the
same row in the same column or on the same diagonal so let\textsf{'}s first
write a function that finds out whether Queens threaten each other
so on the chess board it is clear that each Queen must be in a different
room if any of the two queens are in the same row they they threaten
Charlie so we'll just take a shortcut and the Queen if every Queen
will be in the next row always and the only question is in which column
it is so the integer coordinates here is a column and these are columns
and we assume that they're all in consecutive rows so this function
will compute the condition that some Queen in this position in this
column is not threatened by any of the previous Queens given in the
previous rows with columns specified here so that is when X is not
the same as other X so they're not in the same column and when they're
not in the same diagonal so diagonals are computed by differences
row minus column row - come on your plus column so these are the two
diagonals alright so now how do we find all solutions of the hit Queens
problem so here\textsf{'}s a straightforward just to be quicker let\textsf{'}s say the
row is the set of indices 0 1 2 and so etcetera 7 now x1 is the column
of the first or maybe row of that says I want to say so x1 is the
column of the first clean x2 is a column of the second Queen now we
need to check that the second queen is not threatened or does not
threaten the first so then we iterate over the column for the third
queen and then we check the threat that the third queen is not threatened
by the first we already know that the first two don't threaten each
other so we all need to check that the additional Queen does not threaten
the previous columns and so on at each step we check that the additional
Queen does not threaten the previous Queens and the previous Queens
already find so this is the entire code and then we output the columns
for the Queens that we found the result is going to be a sequence
of sequence of integer because we yield sequence so each of our containers
is a sequence so all the types here are sequence and the result is
also a sequence but the type of element is different is sequence of
integer no and we just check that there are 92 solutions we know that
there are 92 solutions now let\textsf{'}s generalize this example to solve
any Queens problem that is n by n board with n Queens and we do the
same thing you notice here we had hard-coded their eight Queens and
all this code has to be now generalized which is done in the same
way as before by introducing recursion so how do we do that so again
let\textsf{'}s rename this to column because I prefer to think about this this
column actually so we define a function that is going to be the recursive
function that adds another queen we have a previous Queens and it
finds all the possible ways of adding another queen and so that\textsf{'}s
going to be our solution so n Queens is going to be {[}Music{]} :
n Queens partial on the required number of Queens and initially we
have none no Queens already selected so this function says I want
to add this many Queens and here are the initial here are the previously
selected kunas so we do the same as we did before so X is going to
be the column of the next queen then we check that the next queen
does not threaten previous Queens then we find the sequence of the
new Queens and call so these are the newly selected Queens after the
filter line so after this line we are sure that the X is an admissible
column for the new queen so this is going to be the sequence of the
Queen we found and we call the same function recursively so now we
need to add n minus 1 new Queens and here are the queens we found
so far so rest is going to be a sequence of integer and we append
that sequence to the X the X is being the queen we found and then
we're done and so to verify that this is correct I run the test for
eight nine ten and eleven Queens and check the links and it is known
how many solutions there must be look at this page here that I found
nobody really knows how to compute these numbers without numerating
all the Queen positions these numbers seem to be very hard to predict
otherwise so this is how we solve problems like permutations and traversing
a solution tree and filtering out solutions that are undesirable in
some way and finding the list of all solutions notice just a comment
here in all these examples functions that are in person are not actually
tail recursive because the recursive call occurs in the for yield
block and it\textsf{'}s in other words inside some deeply nested flat map somewhere
all these are translated into nested flat maps so if you look at this
also this is a recursive call you see this little symbol here so that
is the IntelliJ telling me that it\textsf{'}s recursive method but the recursion
is not tail recursion occurs on the right hand side here and so there
is some more computation that is being done after this call and so
it\textsf{'}s not a tail recursive call it\textsf{'}s not the last computation being
done the tail recursive call would have been if the result returned
by this function is the result that the entire call he returns but
that is not so after this whole there is more computation to be done
so this is just a short comment here that these non tail recursive
functions are certainly not great in terms of safety because if for
any reason you need a large number of recursive calls that will blow
up the stack give you a stack overflow exception there are ways of
making this stack safe but this is out of scope for this tutorial
right now we will talk about it in a later tutorial how to make monadic
recursion Starke safe it is slightly more involved than usual recursion
because the recursive calls a curve in a freon block under magnetic
flatmap context so that would be I will discuss in a different tutorial
so the last example for the list like Munez is a slightly different
problem that I found quite interesting I worked on it some time ago
when I was implementing and another open source project I found that
I have to transform boolean formulas from distributed normal form
and token sorry from disjunctive normal form into conjunctive normal
form so CNF is conjunctive normal form and I found that this transformation
is very simple if you formulate it in terms of the West model so let
me show you the code it\textsf{'}s really I'll explain now what it means to
transform between these normal forms in case you're not familiar with
the boolean logic it\textsf{'}s not difficult at all it\textsf{'}s just terminology
so what does it mean the conjunctive normal form so it\textsf{'}s all about
boolean formulas like this one so we have boolean operations or and
sorry and so these are boolean operations and the boolean formula
in general can have any combination of these boolean operations now
we say that the conjunctive normal form is when the formula has the
the shape has already it has some parentheses that are connected with
and and inside the parenthesis there all only or so there is nothing
no end is allowed inside the parenthesis no or is allowed outside
the parentheses so that is how we define the conjunctive normal form
and disjunctive normal form is the opposite inside the parentheses
the and only is allowed outside the parentheses the or only is the
left so these are these the normal forms and why are they important
at all the reason is any boolean formula can be transformed into one
of these forms into both actually whatever you want that the reason
is there are boolean identities for example the or and the end operations
are distributive so you can you can expand the brackets or the parentheses
so for instance if you imagine let me let me just make a little comment
here so that it is more illustrative so this imagine that you replace
or with a plus and you replace and with x so that becomes an algebraic
expression that you can transform by expanding the parentheses like
an ordinary algebra and then you can again replace the start of the
multiplication with end and the war with sorry the plus with an or
and you put parentheses around this and then you have a valid transformation
of william formulas so this is you see on the Left we have conjunctive
normal form because on the left hand side we have only our operations
inside parentheses which are disjunctions and conjunctions which are
and operations are outside so the simple expanding of brackets or
expanding of parentheses in the sense of ordinary algebra is what
transforms one of these normal forms into another so in this example
we will implement these transformations will implement the transformation
left responds to expanding brackets as a symbolic computation in order
to do this we need to represent the formulas in some way symbolically
so we will do this by using sets so let\textsf{'}s use a type parameter T as
a type of represents individual prepositions in the boolean formula
we won't do anything with that value it will be symbolic for this
reason just manipulate sets of these values of type T and so our in
our representation the normal form already forces us to have this
structure that there there is a one or more actually zero or more
parentheses and outside it\textsf{'}s always the boolean and and inside is
always boolean over so all we need to say is there is a there is this
set that has a and B in it and there is this set that has CD in it
the water of course is immaterial because any of these designs be
Jorge so sets are sufficient to represent this and then we have a
set of these two so the outer set will be impossible the boolean conjunction
and between these and the inner set will be implicitly the boolean
disjunction between lives so that is going to be our short representation
of the boolean formula so now let\textsf{'}s just briefly consider what would
be the true and false values in this representation the value true
is the empty conjunction which is a conjunction of no parentheses
and that\textsf{'}s empty set the value false is an empty disjunction which
means we do have one set of parentheses but there is nothing inside
it so that\textsf{'}s a set of a single empty set now the disjunctive normal
form has the same representation in terms of data type it still sets
of set of sets of T but it just that the other said now is the disjunction
and the inner set is conjunction so because of this the true and false
are represented in the opposite way so the true for this DN F is the
set of empty set its if you are wondering why is it that empty conjunction
is true while conjunctions are abundant so if you have some non empty
conjunction and you imagine that you have a conjunction of that with
an empty conjunction that shouldn't change anything and so that\textsf{'}s
why the the empty conjunction must be true because the conjunction
of true and X is X the same as with false false is the empty element
for the disjunction 108 so that\textsf{'}s why false is the empty disjunction
so now as I just showed you it is easy to convert one end to the other
you just need to expand brackets so let\textsf{'}s see how we can expand brackets
so let\textsf{'}s just define these types type constructors so that we can
distinguish them more easily the equality we just define this for
convenience to compare we want to run tests and want to convert one
to the other and compare results so these are our presentations of
true and false as discussed so let\textsf{'}s think about how we can expand
parentheses or brackets here for example so we have a set of sets
and we need to prepare a set of these sets of them so in order to
do this transformation using a functor block let\textsf{'}s go like this so
X goes over this set Y goes over that set and then we need a set of
all sets that has one X out of here and one way out of here right
okay see a deep B C B so that is easily accomplished we have X from
the first set a quiet from the second set we just make a set that
cascada means x and y so that\textsf{'}s going to be the result so if we just
had two sets of parenthesis then we would write code like this so
now we need to generalize this code so that it is applicable to any
number of parenthesis not just two and we do it the same way that
that we generalized before we write this code once and we use a recursive
call so let\textsf{'}s do that so the the trick I'm using is that I need to
check that the set is empty actually I I can check that I can do in
the previous code examples check that it\textsf{'}s empty and if not take the
head a slightly more visual and clear way of writing the same code
is to use head option so head option is defined on the set remember
V is the name of our data element inside the case class so that\textsf{'}s
just our set of sets we take a head option the head option is going
to be a set or other option of a set and we match that if there is
nothing that means we have a false so we could have put this CNF false
here actually just to be more visual then we have the case when it\textsf{'}s
not empty so then we have the first Clause we need to let X go over
the first Clause and then we need to do a recursive call on the rest
so in this example over just two we need to go over the second one
but actually in a recursive call with will have more than one y in
here so let\textsf{'}s take all of these waters is going to be then set Y are
all other terms that are connect converted to cmf by the recursive
call and so now we have an X which was chosen from the first set of
parentheses and all the Y\textsf{'}s is the rest of the CNF that was computed
by the recursive call so now we just need to concatenate these sets
and that\textsf{'}s the result and that\textsf{'}s actually the entire code so that\textsf{'}s
very simple in order to run we need to actually simplify things because
it turns out that simply expanding brackets will not produce results
that are identical here\textsf{'}s an example if you have this kind of thing
this kind of boolean formula it\textsf{'}s actually the same as this boolean
formula because this entire formula is true only when this is true
when this is true then here we have true we don't need to compute
anything else here I already have true in this set of parentheses
inside here so this can be just ignored this can be simplified away
it is unnecessary to compute any of this so this simplification can
be just made by by saying well is there any clause well these are
called closes is there any clause that is a subset of another Clause
so for example this Clause is a subset of this one if so then we can
ignore this larger clause and this is what this code does it\textsf{'}s sort
the closes by size and then it finds what are the closes that our
subsets of another and then if so we ignore the larger Clause which
is to the previous and if not we don't ignore it so this is the code
that simplifies using a fold and these are tests so for instance this
is the example and actually another interesting property is that this
function is its own inverse if we convert from DNF to CNF and then
we want to convert it back we can use the same function to convert
back this is so because expanding brackets is an operation doesn't
really depend on what operations are in and out of the brackets as
long as they are distributive and they are distributed in the boolean
logic in both directions and so it\textsf{'}s the same operation the enough
to CNF it\textsf{'}s the same as CNF to DNF it\textsf{'}s its own inverse and the test
verifies that go dnf2 CNF and then we first we convert this and then
we can write back and it\textsf{'}s the same thing I would like to add some
more examples of linear algebra manipulations and to illustrate certain
properties of the function block these are examples taken from the
standard Scala library documentation I rewrote them to be slightly
more functional clear so the first example is the computer transpose
of a matrix so in the matrix is represented as a sequence of sequences
and the result is again sequence of sequences so how do we transpose
a matrix it\textsf{'}s actually not so simple because for instance the first
sequence in the result must be the sequence of all first elements
of the sequences listed here the second sequence in this result is
the sequence of all second elements of these sequences so how do we
get all second elements of sequences we need to know the index 0 1
2 and take that by index so here\textsf{'}s what we do we define this index
as an iteration here going over all indices of the first sequence
in this sequence of sequences so indices and a standard library function
it returns a range such as zero to zero until something zero until
lengths so then once we go over these indices what do we healed we
yield another four expression it seems in other words we yield a sequence
that is computed in a different way how is it computed we need for
example here the first sequence we need to return is a sequence of
elements at index 0 so that\textsf{'}s what we return return I think the name
is back to high perhaps when I hear 0 that will return a sequence
because the for yield returns a sequence of whatever you yield here
a sequence of 0 of elements from X s where access goes over all of
these so in this way we'll return a sequence of 0 of elements of these
sequence of set first elements second elements and so on as I goes
over an indices so you see in order to do this we had to put a 4 inside
of a yield and the result is not easy to read this is a bit of a complication
so nested fours either inside of a yield or inside here you could
put a for else inside here it\textsf{'}s harder to read and probably easier
to refactor in some other way so for instance to make this function
depends on I and XS when they put that function here and make it more
clear what exactly is being computed but that is a core code that
and that can be refactored when necessary for clarity that\textsf{'}s how it
works transposes this into this the second example is to compute a
scalar product of two vectors so we use a zip function we have two
vectors two or two sequences generally and notice I'm using the numeric
typeclass in order to have the sum and I'll do this import so that
I now have syntax I can do star multiplication on the numeric type
you see X is a numeric type and but I have multiplication that I have
addition on it because it\textsf{'}s from the numeric typeclass so the zip
will create me a sequence of tuples of pairs so now for each tuple
I I can write syntax like this I can put a tuple right here I yield
the product so that means the result this entire four expression inside
the parentheses is a sequence of these products now I take the sum
of all these products that\textsf{'}s the scalar product of two vectors this
is a test that it works directly and finally I write matrix product
so again matrix product is kind of difficult because it\textsf{'}s it it has
to be a yield that has a nested four but this is how it works so first
of all we transpose the second Matrix and then we take the scalar
product of one vector the first matrix and the one better from the
second Matrix and we put that into the resulting matrix so that is
I'm not going to go into mathematical details here how to compute
matrix product but this is the way that you can use the for yield
block in order to iterate over these data structures not particularly
visual maybe but at least there\textsf{'}s a no way to make an error in terms
of indices or anything else so that\textsf{'}s an advantage the next type of
monads we are going to consider is the pass/fail units examples are
optional either trying future so as I already mentioned before pass/fail
monads are containers that can hold 1 or 0 values of some type usually
that is interpreted as success or failure so if you do hold a value
of type a and you have success you have successfully completed it
and if you don't then you have failed to compute it that\textsf{'}s how it\textsf{'}s
usually interpreted and these containers usually have special methods
in order to create pass and fail values and an example of this is
a is a try a good example try has methods to catch exceptions if exception
occurred then it will be a fail and if it didn't occur then you would
have a value so that\textsf{'}s a typical pass/fail monad here is a skeleton
or schematic example of a functor block program that uses try we have
some compute Asians that might throw exception so we put them in to
try then we say well X is from this and what does it mean well this
container can have at most one value inside so actually this is not
an iteration at all unlike what we had in the list known as this is
not an iteration this is we're binding X as a new name in case that
this is a success if it\textsf{'}s a failure then there\textsf{'}s nothing to buy in
so this entire filter block will collapsed to the failure remember
that when the collection or the container on the right hand side has
zero elements when the entire for yield or founder block computation
collapses to zero length container this is exactly what happens if
this computation here were to fail if it doesn't fail and we can continue
compute something else in this line nothing can well nothing can fail
provided that F does not throw an exception of course here we can
filter if this returns false then again the entire function block
will collapse to a zero length container so to speak if it does not
collapse then we continue with new computation again here this function
could throw an exception if so then the exception will be caught and
the entire thing collapses when this entire thing collapses the result
is still a try so the result will contain information about the failure
it will just contain no value of type a so there won't be any value
of type a in that case and so on so this is how we write code with
the pass/fail moments we keep assigning new variables here and hoping
for the best so the only way that we can yield the value here is when
all of these computations are successful so there\textsf{'}s no failure in
any of them if so then we owe the value of type a and the result is
their fourth of type try of it now the same rule holds that the right-hand
side of the generator lines must be the same type constructor but
the type of these values could be different in each line the type
of values held by the container may be different but the type of the
container itself the type constructor must be the same or at least
it must be some superclass in Scala we have inheritance so this could
be used to have a superclass and that is used for sequences you can
have different subclasses of sequence but that must be somehow convertible
to the same superclass so another important thing to notice about
pass/fail munoz is that the computation is really sequential so until
this is done until this computation is finished there\textsf{'}s no way to
continue we have to have this X to continue until this computation
is done and if it is successful of course there\textsf{'}s no going no way
to find Z and so we cannot have an X here until this and unless this
is successful so this is really a sequential computation we cannot
continue usually with the next line of the computation until the previous
line is done so this is true even if we have the future functor in
the future factor scheduled computations on different threads and
these computations could be proceeding in parallel but still the computations
are sequential we'll see an example about this {[}Music{]} so once
the any computation fails the entire functor block fails so remember
the number of elements in the entire collection is going to be the
product of the number of elements in the generator lines and sorry
for in if any one of them is zero then the entire thing collapses
to zero so there are going to be zero elements in the result in other
words it\textsf{'}s going to be a failure and if all the computations succeed
if there\textsf{'}s no failure Miniver so for option fader means none for either
failure means a left for try there is a failure constructor for future
there is a failure constructor only when all of them are successful
then this entire fungal block will have a value as a result just one
value also filtering can make it fail so the benefit of using the
for yield syntax with a type constructor such as option either try
and future is that you don't need to write code with nested if-else
or match case expressions you could have written this code with just
match case first you compute this drive then you match the result
if it\textsf{'}s successful then you get an X then you compute this and you
if this is successful then you compute this and so on then you match
on the result so it will be a bunch of nested if-else or a bunch of
nested match case that kind of code is hard to read hard to modify
this is kind of a flat flat looking our code that is easier to read
so you see this has to be done this has to be done the code is logically
flat that is the advantage it\textsf{'}s easier to understand easier to read
of course they have to be get used to the same that the type constructors
I'm just writing out again that these must be familiar to you by now
these are disjunctions so the pass/fail Monitor typically disjunctions
now the tri is equivalent to an either where the type Z is throwable
which captures exceptions and then there is this data type a so the
typical reason we use these moments is we need to perform a sequence
of computations each of these computations might fail and we cannot
continue if one of them fails we have to report the error somehow
so we just make this explicit with return an error value which is
not to crash it is not sometimes exception or error situation it\textsf{'}s
a value that captures the information we want to give about what happened
and why things failed and so that\textsf{'}s the typical use of a sphere moniz
let\textsf{'}s look at some work examples the first example is to read Java
properties so Java properties are strings which are held in the system
dictionary of key value pairs so you have a key which is a string
and a value which is a string so here\textsf{'}s an example we have some properties
and we want to compute something for example for the client we want
to find out which corporation the client is working for for that corporation
what are the orders as were posted and then for the order we want
to have the amount or something like this now the Java API is such
that you can say get property only when you do get property that returns
a string but actually it could return null if this property does not
exist and so in Java this is the usual reason for null pointer exceptions
so some function returns null but you didn't expect it you start following
methods on that you get a crash so in order to avoid this and make
it safe let\textsf{'}s put this inside an option so the option type has a function
that you put an option of something and if that something is null
then you will get an empty option otherwise you would get a non empty
option so that\textsf{'}s a very convenient function whenever you have some
Java API that can return null in order to signal that something wasn't
there or something was incorrect wrap it into an option like this
it becomes safe and now the code we write looks like this first let\textsf{'}s
say somebody gives us the client name we want to return the amount
of the order now it might be that this client is not found where the
corporation is not found or ordered is not found in this case we cannot
return the amount renamed this function for clarity I cannot return
the amount in this case so I will return an empty option otherwise
I will return a non empty option with the requested amount so this
is the idea are always return a well defined value just that sometimes
this value will be empty or it will not contain the data that I was
supposed to return because I can't return love data and so I write
a for yield with these values being strings but because this is a
monadic block whenever one of these is now this entire block would
collapse to an empty option so I can write the code as if everything
is good so this is the so-called good path or happy path but I know
that whenever something is null here either the corporation\textsf{'}s property
does not exist or orders property does not exist then this entire
for your blog will collapse into an empty option so I'm safe to write
code here last line I'm trying to convert the string value to integer
now the string value is guaranteed to be not novel but it could be
incorrectly formatted so it\textsf{'}s conversion to end might fail with an
exception no matter I'll grab that into a try so after that exception
is going to be caught and then I convert that to option so there was
this helpful method to convert to try values to option so if try had
I would have an empty ocean here and then everything will collapse
I'll return an empty option so you see this code has no if else it
looks very linear and yet it\textsf{'}s completely safe all the errors are
handled invalid non integer values either our handle they're going
to be ignored so the test is that if I want the order mount for client
3 there is no client 3 and the second example is to obtain values
from computations using future so this is an interesting example in
order to work with futures I make this import just for simplicity
so imagine I have a long computation now I'm going to compute something
not particularly useful maybe some kind of long Sun with cosine functions
and whatever it\textsf{'}s not particularly important I just want to have a
computation that takes time in order to save time this computation
I want to make it in parallel so I put this computation into a future
and I'm going to try to compute them in parallel now here\textsf{'}s the code
I write I have this auxiliary function time which will return me the
result and also the time it took to compute the result so how do i
compute the result well I have a 4 for yield which uses the future
so that the right-hand side of these computes the future of double
and therefore the left hand side is double so the type of the container
in this for yield block is future it must be the same type throughout
the container so that is future and the result type is going to be
a future double as well and so this looks like I am performing first
along computation which is going to be in the future when that computation
is done I perform another long computation using that value as input
which will call this function and create a new future and what future
will depend on this X because the computation uses the X C and so
I cannot really start this computation until this one is finished
putting future\textsf{'}s in a for yield block will sequence them in other
words first it will wait until this future has done its computation
to return its value and then will put this value in here call this
function and start a second future wait until that is done put this
here and wait another feature I should I should return I should return
Z probably to be slightly less useless for this block in any case
the result is that these futures are sequenced one of them waits until
the other is done now imagine that these computations were not depending
on each other well here they do this computation depends upon respects
imagine that that weren't the case if that were in the case let\textsf{'}s
say we have three computations and these parameters are known in advance
then we could have started started all of them up front so look at
this code so we create three futures of all of these part of type
future we create three futures and in Scala future is a funny type
because once you create a future you already schedule is to run there\textsf{'}s
no separate operation to started or to run it once you make a future
it means the system will attempt to run it already there will be probably
already running process so this means these three computations are
probably already running by the time we are here what do we do here
we make a four-year block which is superficially similar to this one
we just put the computations in variables and put them here so the
result however is going to be faster because all these futures are
started at the same time yes here you wait for them but they already
started all in parallel so you would just wait less you would first
wait until this is done and while you wait maybe this is already done
so this second wait will take no time at all and so the result I expect
to be faster so in this test I'm fringing how long it takes and the
typical output I got in my tests was like this so the first sequential
futures it took six seconds and a second took 2.7 seconds so this
is not exactly three times faster but it is more than twice as fast
in any case we were able to do this only because the three computations
don't depend on each other if they do is there is no no way to speed
it up it\textsf{'}s just there\textsf{'}s no advantage in putting that computation in
the future if you cannot do it in parallel for this at least for this
test let\textsf{'}s look at the other example example 3 which is we want to
make a rithmetic safe and we use the either type to return error messages
so that\textsf{'}s a very common use for disjunction type so let\textsf{'}s make this
type that has either string or double in it and string will be an
error message of some kind meaning that we cannot compute the double
value strictly speaking this is not a factor because it doesn't have
a type parameter so I'm just abusing well I'm the either is a function
I'm using the inner function and I'm just specifying the type to double
because this is going to be in my example but actually this is a functor
with double as a type parameter so we could think about this as a
function and that\textsf{'}s what it is how we are going to use it so the idea
is that if there is a operation that could fail then we return the
left with some error message and if there isn't success in returning
right with that value so if we already have a double and we do an
implicit conversion of that to the safe double by just putting a right
around it and in this example the only operation we're concerned is
division so we can divide by zero we don't want to try to do it do
that we want to return an error message and so that\textsf{'}s what this function
does is a safe divide it would tell tell me what I tried to divide
by zero so hopefully it will help me in my debugging so then that\textsf{'}s
the point of this example so here\textsf{'}s the code that I use so instead
of writing well x equals one and I've put everything in a functor
block and you see quite unlike the things we did with sequences these
are not loops at all these are not iterations in any sense for yield
is not a loop that is a important point that I would like to make
there is no iteration going on necessarily it\textsf{'}s a monadic sequencing
operation rather so we are sequencing computations that might fail
if they fail we want to fail the entire computation if any any of
the steps fail so here is what we do X is assigned to be one that\textsf{'}s
not going to fail because there\textsf{'}s no division here is a division let\textsf{'}s
say no it\textsf{'}s not going to fail but we still use a safe divide and then
we do this so the result is going to be always safe double so here
the right hand side of the generator arrows is either of the type
either already is a safe double or it\textsf{'}s automatically converted to
safe double so safe double is a type of the right hand side of this
look and here\textsf{'}s an example where it fails so we divide by zero we
do exactly the same things but because this step divided by zero the
entire thing collapses we never get here and the result is a left
of that a last example for the pass fail is to sequence amputations
that may throw an exception so here we sequenced computations that
could divide by zero and here we just have arbitrary exception so
here is what we do dividing by zero throws an exception for integers
it doesn't for doubles it gives you a not a number but for integers
it throws an exception so imagine we have some functions that might
throw an exception we wrap all of this into a try and then we have
code like this and so this is completely safe the result is of type
try of int and we can in examine the result to see that it\textsf{'}s a success
or a failure so we do match expression and then in this test I know
it\textsf{'}s going to be a failure because I first what what did I do if one
of one so I divide two by one the result is two then I subtract 2
minus 2 the result is 0 then I divide one by zero so I know I know
it\textsf{'}s going to be a failure but in principle here you could have a
case of success and that\textsf{'}s how you use the pass/fail chain so you
put everything in to try the result is also going to be a track so
I can just add the type here for clarity you don't have to write this
but for clarity I want to the next type of monads I'd like to talk
about are tree like monads so what are the tree like moments here
are some examples these are type constructors defined recursively
and I use the short type notation so it\textsf{'}s easier to understand what\textsf{'}s
happening so the binary tree is either a leaf or a pair of two binary
trees so that\textsf{'}s a familiar type perhaps and because it\textsf{'}s recursive
then this can be again either a leaf or a pair of two binary trees
and this also can be maybe a pair and so this is a pair and this is
another pair that just keeps splitting until it ends with a leaf another
stability of generalizing this kind of construction is to say well
actually this is a functor this is a pair of F and F let\textsf{'}s say that
the pair of F and F is a function y 2f let\textsf{'}s call this one term s
shape and so then it will be s of F of ready let\textsf{'}s take arbitrary
function s not necessarily just a pair so it could be triple then
the tree would branch in three branches at each each point instead
of two branch so we can just parameterize the shape of the tree by
an arbitrary function S this factor could be actually arbitrary could
be list when you would have a rosetree what\textsf{'}s called where the branching
can be arbitrarily large in ten you point could be any factor so that\textsf{'}s
what I call an s-shaped tree where s is a funder functor shape dream
another interesting example of a tree is when both the leaves and
the branches have the same shape so the leaf must have a pear and
the branches must be too and analogous generalization is when you
have functor shaped leaf and a functor shaped branching so these are
perhaps more rarely used but I found them interesting to Q consider
most examples for all of these you can implement flat map and we'll
look at examples of how to do that so here\textsf{'}s here\textsf{'}s how you implement
a flat map for a binary tree with binary leaves this is our first
type constructor here I'm sorry this is a third type constructor here
the binary tree with binary leaves so how do you implement flat map
well let\textsf{'}s first define the type so the type is this it\textsf{'}s a disjunction
the first element of the disjunction is a pair of a a so just follow
the type here the first element of the disjunction has a pair of a
a the second element the second part of the disjunction is a pair
of two three factors themselves so I call this B X and B Y now we
need to implement a functor instance for this and I have my own typeclass
here called semi monad just for convenience where I can define flatmap
{[}Music{]} so to define functor is pretty easy obviously if you have
a pair of a a you just map both of them with a function f and if you
have a branch then you recursively map each part of the branch in
the same way so flat map works actually quite similarly except for
the leaf if you have a leaf the leaf has two elements and so you have
a function that takes the leaf and returns a tree so now you have
two trees so you can't have a leaf if two trees in it but we can have
a branch and so we put these two new trees into a branch here is how
we can implement flat map for a functor shaped tree and here I make
a more abstract formulation where I have actually a tree that\textsf{'}s permit
rised by an arbitrary function so that\textsf{'}s a functor shaped tree so
the leaf is just one element of type a one data item and branch is
a functor s applied to the tree so it\textsf{'}s a functor shaped branch how
do we implement the functor instance and how to implement the semi
Monod instance for this tree this is a little involved but the sin
it\textsf{'}s just a syntax that\textsf{'}s a little complicated here because we need
to parameterize by an arbitrary function and so the type constructor
is this so the factor s is fixed the type parameter is free the map
works by matching so if it\textsf{'}s a leaf and we map the leaf value with
the function f if it\textsf{'}s a branch then we we use the map function only
the factor s which we should have because we assume that s as a function
and the function we use to map is the recursive instance of mapping
the same tree here is what we do where it were in this case so if
we want to map a to be we map a to be over here recursively and then
we map over the function s because we know it\textsf{'}s a function and flat
map works similarly if we have a function from A to F B then this
is just mapped to FB by itself and we haven't have been and this Maps
afraid to have be recursively and then the out the outer layer of
the Thunder s is mapped using its own map function so here\textsf{'}s how it
works so we have a function f from a to the tree if we have a leaf
and we just put that entire tree instead of the leaf or as one can
say we graft the subtree at this point and if we have a branch then
we map over the branch which it because we have the outlaw outer layer
on the family yes so we've mapped that and underneath we used the
recursive call to the flat map here\textsf{'}s an example of an entree like
type constructor it is a disjunction of this kind so it can have one
a can have two is it can have four A\textsf{'}s and so on all the powers of
two now this type constructor is actually not recursive so it is not
a tree like type constructor it is not one of these cannot be represented
as one of these and it is not a ma not in the usual sense or not a
tree like ma not in any case so a little bit more intuition about
how flat map map works for a binary tree so imagine that we have a
tree that looks like this and we need to flat map it with a function
that takes any so all these are leaves of type a and so a function
f takes a and returns a tree of type B imagine that when we apply
the function f to these three values of type a we get three different
trees of type B so suppose that these are the trees we get so the
tree that has these two leaves a tree that just has one leaf and a
tree that has these two so then if what the flat map is supposed to
do its supposed to replace a one with this subtree so instead of anyone
will have this subtree a tree with b2 so that\textsf{'}s this replacement a3
is going to be replaced with this subtree so a3 used to be here now
it\textsf{'}s this subtree so this is the result of applying flatmap to tree
like walnuts its grafts sub trees in places of leaves that plays the
role of flattening so actually nothing is being flattened here in
some in a sense of trees remain trees trees are not flat in the organ
Airy sense and they do not become flat in any sense however what becomes
flat is that we had a tree in the shui for each leaf we replaced that
with a tree but we don't get tree of trees tree of trees is just equivalent
to a tree that is what it means to be flat note that the tree becomes
somehow meant dreamlike but a tree of tree of B can be seen as simply
a tree of D there is no need to say that we have a tree of trees the
trees already branching enough so that\textsf{'}s what flattening does for
trees typical tasks that dream tree like monads perform are traversing
a tree and replacing leaves by sub trees are grafting leaves grafting
sub trees at leaves one example of doing this is a user is transferring
a syntax tree representing some expression where you substitute sub
expressions in it so if if this is some expression tree then you want
to substitute sub expressions instead of leaves and that\textsf{'}s it kind
of typical tasks that tree-like Mona will do so let\textsf{'}s look at worked
examples the first example is to implement a tree of strength properties
so let\textsf{'}s take a look at that so probe tree is going to be our factor
so just for simplicity I'm going to put a map and flatmap into the
street right there we'll implement them in case classes that implement
the trait this is not necessarily how you want to do it but if this
is your own type it\textsf{'}s easy to do that if it\textsf{'}s not your own type so
that your you cannot change the source code for some somebody else\textsf{'}s
type constructor then you need to do typeclasses and add map and flatmap
using type 1 system I just want to make it short okay so what is this
type so he has a leaf which has a value of a and also it has a fork
which has a name and a sequence of other trees so it\textsf{'}s a it\textsf{'}s a slightly
different shape so the forks are named so there\textsf{'}s a name and it can
have zero or more sub trees here is a sequence so it\textsf{'}s kind of a rosetree
with named branches so how do we implement map well if it\textsf{'}s a leaf
we just map the value if it\textsf{'}s a fork then name stays the same but
each of the trees is mapped with its its own function this is a recursive
call Raney however the recursion is hidden it\textsf{'}s not the same function
this function on a different object what\textsf{'}s the same it\textsf{'}s still recursive
flatmap so if we are in the leaf we need to replace value any with
a different proper tree we just graphed that probe tree in place of
the leaf that\textsf{'}s a standard thing to do and flatmap for a fork is just
mapping so basically this is our example of a functor shaped tree
this was this example where the founder s has a specific type it is
a product of a string and the sequence of a or a sequence of of trees
so that is just a special case of the construction of a functor shape
trip right so here is an example we have a fork with named a1 and
it has a leaf one a leaf - and another fork named a - with leaf 3
now we can map on the stree with the function that adds 10 so then
each leaf will get 10 added to it the structure of the tree remains
the same after mint because map doesn't graft anything it just changes
the values and leaves now let\textsf{'}s look at this code we want to look
at the leaves and somehow transform leaves that are small and small
is less or equal to 1 so here\textsf{'}s the code for this so we we said X
goes over tree which means that actually the value of X goes over
leaf values because that\textsf{'}s the values in the tree that are being being
used and then if the leaf is larger we keep it as a leaf otherwise
we make a fork in it and call it small and put a leaf inside this
work and so we yield that so this code transforms a tree the tree
that we had here has fork a 1 and so on it transforms into this so
the leaf one is a small and instead of leaf 1 we have now a different
tree this one everything else stays this sparkly one but me maybe
format this so that it\textsf{'}s easier to see easier to compare the two different
trees before it after the transformation so the only difference is
that instead of leaf 1 we now have this fork with extra information
so that\textsf{'}s the result of transforming the tree so you see this for
yield is a kind of a loop but it\textsf{'}s a loop over a tree and it can transform
a tree into a new one so just to repeat for yield is not really iteration
it\textsf{'}s more like a general kind of operation that goes over your container
and depending on what the container is like it will it can do many
things so for the tree like monads it\textsf{'}s usually tree traversal exactly
the same computation written by flatmap syntax to study for yield
is this the second example is to implement variable substitutions
for an arithmetic language so what do I mean by an arithmetic language
so imagine we have a symbolic manipulation program wants to manipulate
expressions it can be a compiler or it can be some kind of calculator
program or anything else like that so that kind of program needs to
work with symbolic language that does some kind of reputation and
let\textsf{'}s say every filter so for us we're going to have a very simple
language language is going to have variables and multiplication and
it will have constants integer constants and that\textsf{'}s it so to define
this language we define a disjunction so basically this is the term
let me write down maybe the short notation for this term is it was
a so int is one part of the disjunction which is called Const the
second part of the disjunction is the variable which is called the
var and the third part of the disjunction is malt which is two terms
so this is the definition of the type this is recursive and you see
this tree like except that we have this extra thing here now that\textsf{'}s
fine that doesn't carry modify and structure so much against that
belief now can have an extract information so let\textsf{'}s define map and
flatmap oh this is trivial and I'm going to go over it this is the
same structure we found before and now let\textsf{'}s implement variable substitution
so what does it mean so suppose we're so expressions in this language
will look like this as a constant times VAR times constant times more
and so on there\textsf{'}s nothing else in this language except constants variables
on multiplication so we can do that in any order we want and that\textsf{'}s
all now there are two operations we can do use a map and flatmap using
map I can modify variable names so we can for example append X to
every variable name so here\textsf{'}s what the result will be depending X
2 variable mass second thing we can do is substitute variables so
for example instead of very well a we can substitute this expression
so we can substitute new expressions of the same language instead
of variables and that\textsf{'}s usually what mathematical expressions do variables
in mathematics are substituted with new expressions of the same kind
so that\textsf{'}s what we are going to do here so let\textsf{'}s substitute there I
will a with this expression and the variable B with that expression
and we do it like this so X is going to range over there Able\textsf{'}s wine
is going to replace X so we'll do I instead of X if we just said for
excellent expression yield X that\textsf{'}s going to be the same unmodified
expression as before so we modify we say Y is is that and well we
just threw an exception here just so that I have some simple example
but basically if the name of the variable is a then we substitute
this otherwise we substitute that so the result is correct finally
we come to the non-standard containers for single value monads they
are not really single valued in the sense that they are not equivalent
their container with the single value container with a single value
is identity unit or identity functor it just a continuous has a value
agent that\textsf{'}s not what they actually do but they are similar to that
they can be imagined or reasoned about to some extent thinking that
the only and always hold one value actually the meaning of the single
value units is that they hold the value and also they have some kind
of context together with that value and when you do computations then
contexts play a role they can be combined and they can also be used
to do something and usually for these moments we have methods that
insert a value one container hold one value so that\textsf{'}s necessary to
be able to insert that value in there somehow and also usually there
are methods to work with this context and we will now look at five
examples of single value moments and we'll appreciate the variety
of what this idea can do holding a value in a context so the typical
tasks that single value Mullins do are to manage extra information
about computations as you do the computations along the way and also
to perform a chain of can rotations that have some kind of non-standard
evaluation strategy so in the first case where we are managing extra
information the context is this extra information in the second case
when we are changing computations with some non-standard evaluation
strategy for example in synchronous computation or lazy computation
then the context is that what makes the evaluation strategy non-standard
so it\textsf{'}s not a value this context cannot be just seen as a value in
this case it is kind of the way that we do computations or extra effects
or maybe side effects that occurred during the computation for something
like this so we'll see examples of both of these kinds so let\textsf{'}s look
at the first example it\textsf{'}s the writer monad the writer monad is defined
as this type constructor very simple is just a pair of a data item
of type a and a value of type W where W must be a mono it or a semigroup
suffer for this to be a full mode add W must be a monoid and for this
to be a semi mode add W can be a semigroup to remind you the difference
between 100 and semigroup a mono it has a unit element or identity
or empty element which is a selected element so that you can combine
it with other elements without changing those other elements a semigroup
does not have that element it\textsf{'}s just a set with the binary operation
that is associative so here in this tutorial we can consider a semi
munna des writer as well because we're not necessarily so interested
in the mona fully form on that right now and so we will assume that
w is the same so this w will hold some kind of logging information
about our computations and logging information should be able we should
be able to attend one piece of logging information to another and
that\textsf{'}s the semigroup operation so let\textsf{'}s look at the code so in this
example we have so I defined the writer as semi moonlit where a is
our data type and s is a semigroup and so that is just a pair of a
and s why I wrote s instead of W let me just make W out of this just
so that I'm consistent with my slides so we can easily find the instance
of functor and instance of semilunar now instance of sending one is
just flat map so semi-modern is typeclass that just requires flat
map with a standard type signature so how does that work well obviously
functor works by mapping mapping the value but not changing the log
so log is this information that we logged about the computation now
the flat map has this type signature so when we do the flat map we
need to take the previous value which is already a pair of a and W
then we map a to another pair of BMW now we have to double use so
we have FA dot log and FB deplored FB was computed knowing this and
so we combine the two log values by using the semi group operation
so this is how we could use this in practice imagine that I want to
record in my log some comments about the operation and the time let
the computations began and the time at computation is finished for
the entire chain of computations not just for each operation separately
but for the entire chain of computations I want to find begin time
and end here\textsf{'}s how I can implement this I make a semigroup that has
three values and the semigroup type is a triple of local date time
local date time and string how do i define a semigroup instance I
need to combine two logs of this type so the messages I combine by
just appending them with some new line separator but the beginning
end I combine in a specific way further from the begin I take the
first begin but for the end I take the second and second why today
because it I'm combining two operation so the first log in the second
blog and I assume that the first log occurred first and so the beginning
of this entire operation is the beginning of the first log while the
end of this entire operation is going to be the end of the second
log so that\textsf{'}s why I'm putting it like this now this is actually a
semigroup it is associative but it is not a monoid it cannot be read
into mono it so my writer here will be a semi Munna but that\textsf{'}s the
use case so that\textsf{'}s that\textsf{'}s what I want it for so now I define a convenience
type constructor which is the writer with this logs as a type and
i also define a help of helper function that will do the logging so
i have a value i have some message and then I insert the timestamp
into the log and the message that\textsf{'}s very easy mean I just insert begin
and / convenience as the same timestamp and things will automatically
be adjusted as necessary once I combine this with computations made
later so this import is necessary in order to use this machinery with
the same Amanat typeclass and here is the code so these compute things
are fake computations that pretend to take time so they actually wait
for this time but that\textsf{'}s fine for this example so you see I'm logging
so I log in everything with the message and the times will be automatically
looked so I first start with the log int so the integer value so X
so the integer then I add 1 to that X that becomes my life so that\textsf{'}s
going to be 4 and then I multiply by the 2.0 which is a double so
the result will be log double and I'll yield Z in the log function
block so the result is of type log the devil so as usual the right-hand
side of the generator lines is always of the same container type which
is logged this is the container type for this entire function block
this is the function so these are computations in the context of a
factor this is what I call computations in the context of a functor
we write as if these are values we compute but actually these are
inside the function so everything is so as if we return a double but
actually when we compute any factor parameterize by double so logged
double that\textsf{'}s the type of the result let me put it in here for clarity
and the result is 8 so it\textsf{'}s 3 plus 1 4 times 2 now we checked what
the log message is so the log message is actually beginner is 3 then
there is a newline head wound there\textsf{'}s a new line x 2.0 neither our
global messages and also I can check what is the interval between
beginning and end and test checks that this is about right so it\textsf{'}s
20 milliseconds 50 milliseconds at 100 milliseconds together it\textsf{'}s
going to be slightly bigger but anyway not much bigger so this is
the example of using a writer movement in our case it was a semi mu
not actually not a moaner use a writer monad we can easily make automatically
logging computations with keeping track of wall clock time the second
example is the reader movement so the reader monad is also to be thought
of as a container that holds exactly one value in the context and
the context is some value representing the environment some type II
which is given it is read-only you can read it and it\textsf{'}s always available
for you to read so this can be used for dependency injection or for
passing some common parameters that you don't want to pass with explicitly
with every function and dependency injection means that the computation
within the reader functor or with the context of the reader frontier
take this as a parameter automatically they don't depend on what it
is and then you you inject it later so that\textsf{'}s how it works let\textsf{'}s taken
let\textsf{'}s look at an example the example will be that we have logged computations
and the logger is the injected dependency so let\textsf{'}s say performs some
kind of side effects a function of this type and we want to make computations
that use this function but we don't we want to depend on this function
as read-only context so somebody will give this this to us later but
we want to write code now so we use the reader monad which is just
a cat\textsf{'}s reader now cats reader is equivalent to this type which is
just a function from Italy so for convenience we define this type
as a reader of log duration hey so we will understand this container
hence a container that has a single value of a but that value depends
somehow our computations can depend on this logger function in some
way so let\textsf{'}s make a constructor for convenience that will log a message
so this constructor now has a lazy argument X so this syntax in Scala
means that the function argument is lazy and unevaluated until the
function evaluates it so that\textsf{'}s kind of automatic lazy parameter passing
and here\textsf{'}s the code so the log returns a reader with the log duration
in it so it\textsf{'}s a function from log duration to a first we compute this
X here and we time it so we compute the time to actually run this
XC as I just said a result equals x actually because x is a lazy parameter
it is not yet evaluated until I do this so this is when X will be
evaluated and this might take time and so I compute that duration
and then I log it using blogger function and I return the result so
that\textsf{'}s my convenience function so once I coded this I can write code
like that like I did before very similar with now I had I can do add
another set with reading which is usually called tell now tell is
just a function that returns the injected dependency or the environment
or the context and this is just a reader of identity which is a function
from e to e that\textsf{'}s an identity function so using that you can always
extract that dependency explicitly and use it in if you want so here\textsf{'}s
how we do this we say log duration is tell and now we can use that
that\textsf{'}s our logger function we can just use a hand hook if we want
to we don't have to do this because our computations are automatically
logged what we might need to use it for some in some example so the
tail is the usual function that people define for the video moona
all right so how is it going to be tested I'm going to have logger
will just print some message how much it took nearly seconds and then
I'm going to do a run so important I already computed this result
reader but nothing as jim has run yet this result reader is a function
from log duration to double this function hasn't been called yet I
have written the code as if the computation is already done but actually
it isn't yet done it needs to be run still so units of this kind usually
have a method called run and so this method takes a log duration and
it gives me a double and so that\textsf{'}s what I have to do at the end and
so the there is always this printout as we expected it\textsf{'}s about 20
seconds about 50 milliseconds about hundred milliseconds and then
there is this extra ad hoc computation now just one note here so the
usefulness of this technique is that you can separate this code from
this code you can combine these readers with each other you can put
result reader here on the right hand side a generator line because
it has the right type the whatever is on the right of the generator
line must be of type reader of something as long as it\textsf{'}s the right
type a reader of log duration and something you can put it on the
right hand side so in this way you can combine several values of the
reader type income in computation to make a longer computation and
at the very end once you have done all you need you actually run it
at the very end when you actually know what logger you need or what
context you need what dependencies you inject you run it so this is
the this is the event that you can separate injecting your dependencies
from writing code it uses the dependencies and this code looks like
this dependency is invisible here we made it visible because we wanted
to illustrate that you can but you don't have to if I remove this
it\textsf{'}s invisible if you have this dependency your code doesn't get cluttered
with it so that\textsf{'}s this message a third example is an evil unit which
is something that cats library implements we will implement a very
simple version of it ourselves for purposes of illustration the idea
here is to perform lazy computations in other words computations that
are not immediately executed and so in order to do that let\textsf{'}s define
this type so this type is a disjunction is either has a value that\textsf{'}s
already computed or it has a value that will be computed once we call
this function now this function has a unit argument so there is no
nothing we are waiting for but we just haven't haven't called it yet
and so there\textsf{'}s no data that we need to receive from someone in order
to run this function well it\textsf{'}s up to us when we want to run it and
so that\textsf{'}s the point of this monad it\textsf{'}s either a value that\textsf{'}s already
been done and then so-called it\textsf{'}s memoirist in other words if you
try to compute it again it\textsf{'}s already there or it hasn't yet been computed
and then it\textsf{'}s this is a explicit representation of lazy value Scala
has built-in lazy values but sometimes it\textsf{'}s useful to have a more
explicit representation so here\textsf{'}s how it works so let\textsf{'}s define a trait
which is evil like I said the cats library already defines this with
slightly different API but I don't want to use their evil because
I want to show how it works the main function that it has is get so
yet means get give me the value so evil is a same single you monitored
it holds inside it a single value of type it so get me that value
and if that value hasn't been computed yet compute it and give it
to me otherwise if it\textsf{'}s already computed don't give it to me right
away that\textsf{'}s the point of this get and then we have a map and flatmap
because it\textsf{'}s a semi wounded it\textsf{'}s actually a full modded of course
because it\textsf{'}s easy to put a into here so pure would be very easy to
implement it has a disjunction as we have indicated a and 1/2 wave
so let\textsf{'}s see is this one it\textsf{'}s called eval now so it\textsf{'}s already evaluated
now and the second one is a function from unit 2 episodes eval later
it will be evaluated later so to get what\textsf{'}s already valued it is trivial
to get what will be very linear we'll just call that X let\textsf{'}s call
this actually call us if call this ok I don't want to be nameless
we just call that function on a unit argument and we get what we want
implementing the map and flatmap is trivial except well except for
one thing so for flat map we evaluator but what we evolve here we
get in other words we don't postpone that evaluation anymore we already
postponed once so we don't want the postponed twice that\textsf{'}s the point
of flat map so a non flared structure would be that we postpone the
postponed computation so that\textsf{'}s kind of nested postponement we've
want to flatten it so we want to postpone exactly once and so we postpone
wait for the unit but once the unit is given that\textsf{'}s evaluated it was
not postponed anymore that\textsf{'}s how it works now we can define convenience
constructor so this is a pillar which just gives you an eval now and
you can have a constructor for later which gives you an evaluator
and it\textsf{'}s just for convenience see I'm using lazy evaluated argument
in the function just one little comment here in programming a software
engineering community these arguments are called by named arguments
can't be more wrong than calling this I'm not by name they're undervalued
and or lazily evaluated it\textsf{'}s not the name that you pass you pass an
unavailing it'ld expression that needs to be evaluated you don't have
to have a name for it and often you don't so they are not by name
argument they're an evaluate it or lazy evaluated arguments anyway
so what do we do let\textsf{'}s again use our compute helper function that
will introduce delays into computations and here however we do we
can write a for yield block with all sorts of things in it and on
the right hand side we can either put later of something or not off
of something so that\textsf{'}s how we will use this and this way we'll chain
computations that are postponed and computations that are not postponed
so we can combine them very easily with very clear organization of
the code and the result is again eval in so this result is probably
postponed and we can get it and when we get it it will print things
so this is the output not you yet so when you create a value of this
type it doesn't necessarily compute anything and you see this because
this message is printed first so this message is printed first and
only then these two messages are printed that we have here so this
might be counterintuitive but actually when you do this none of this
is run yet again this is a kind of Munna that has non-standard evaluation
strategy it doesn't run immediately when you do a for yield it will
make these computations postponed you have to run it so the run for
this model is called get and so that\textsf{'}s when these two lines will be
printed so this could be a little counterintuitive when you work with
these single single value mu nuts because many of them encapsulate
non-trivial evaluation strategies reader monitor was at the same kind
once you do this nothing is that done yet the function is constructed
the function still has to be called so that\textsf{'}s the REM call here it\textsf{'}s
a gate call and that actually runs the moment the first example is
continuation unit this is not necessarily very clear what it means
I prefer to call it a callback monad but continuation monad is a standard
name for it so I will go into detail now but how it works the purpose
of this moment is to chain asynchronous operations operations that
register callbacks so it\textsf{'}s managing callbacks that\textsf{'}s the main use
case for this moment there are other use cases one of the main use
cases is this one so let\textsf{'}s look at the code an example I will show
is using the Java input/output operations on files and using asynchronous
file operations so these are called asynchronous file channels and
there are asynchronous in the sense that you start reading the file
and you need to pass a callback that will be called when it\textsf{'}s finished
reading it so this is asynchronous code in this example is to read
a file so I created a sample file which is this one which is very
short I'm going to read it into a buffer I'm going to write the same
thing that I just read into a different file into this one then I'm
going to read that file again and compare the results so that I verify
that whatever I have in this second file is the same as what I had
in the first file so to read it into a second buffer and assert that
the buffers have the same strings in them now you see how much code
was necessary to get that done all I did is to read one file write
the contents to another read that contents and compare with the first
look at how much code I have to write using the Java look at look
at this nested thing it\textsf{'}s a deeply nested combination of functions
this is a typical problem with asynchronous API is that you use callbacks
callbacks get nested let\textsf{'}s see how he how that works the API is like
this you make a file channel then you call the read function on it
which takes a buffer and some parameters just in my case are just
0 and then it takes a callback now the callback is a new object of
type or value rather of type completion handler and the completion
henry has two functions inside one is called when there\textsf{'}s a failure
and the other is called when there is success the file has been read
so for the purposes of this example I'm not going to handle errors
I'm just going to print that errors occurred so I'm just going to
concentrate on the happy path on the success so the callback for success
is this not in my code what I have to do is I need to well I need
to wait until this callback is called there\textsf{'}s no way to wait for it
so the only way I can write my program is to write the rest of the
program inside this callback so that\textsf{'}s how I get into a deep nesting
so the rest of my program is inside the callback I'm closing the channel
rewinding the buffer opening another channel and then I call the right
function on this other channel the right function similarly takes
the buffer and a completion Handler a new completion Handler with
its own callbacks the failed callback had print a message a completed
callback will be called when the second file is written successful
there is no way for me to find out when that happens so right because
I already called the right function the right function has finished
very quickly and then the file has started to be written after the
right function has already returned there is no way for me to figure
out when is completed function will be called this callback therefore
my entire rest of the program must be inside the callback I closed
the alpha channel I make another input channel I read and with a third
callback print message when failed completed and the entire rest of
my program must be in here so for example I want to check that bytes
were correctly read and correctly and incorrectly written I cannot
really pass this information to somebody else outside of this callback
unless I use local variables global Global mutable variables where
I I write some information and a semaphore that somebody will have
to wait for on the thread this is horrible very hard to write such
programs or I need another callback that I will call here to pass
this information I could do this if somebody gave me a call back such
as report result I could put that result into the callback and call
it so somebody else will then have to continue writing this kind of
code that everything is inside the callback because of this problem
people call this people usually say this is callback hell all these
callbacks that forced you to write the rest of your program inside
a deeply nested structure wangus a continuation monad manages all
this in a much better way so let\textsf{'}s rewrite this code by using the
continuation or not now the type of the continuation monad is going
to be this it is kind of not clear why this type is useful but let\textsf{'}s
look at this and consider what it is doing this type is a function
that takes this as an argument now this function itself this is a
callback this is a typical callback that we had in the completion
handler it took it takes some result or some in input and returns
unit so a function that takes data and returns unit that\textsf{'}s a typical
callback signature so the continuation monad is something that consumes
a callback it\textsf{'}s a consumer of a callback that\textsf{'}s how we can interpret
this type what can I do how what does it mean to consume a callback
well you can use the combat the only way to use the callback is to
to run it to give it a value of type a and run this function and then
whatever it does you don't know but that\textsf{'}s what you can do you can
call it twice if you have several different values a you can call
it many times or you can omit omit calling it at all if you don't
get any values of type way so that\textsf{'}s what you can do with a callback
so when you create a value of this type it means you have created
code that will do something possibly obtain one or more values of
type a and run this callback on those values that\textsf{'}s what the continuation
what it is doing so creating a value of this type of this continuation
type means you have created your callback consumer or your callback
logic that\textsf{'}s why it is so useful for situations where you need a lot
of callbacks you should not use callbacks like I just showed you in
this complicated looking code you should use the continuation monad
here is calm so in our case let\textsf{'}s come let\textsf{'}s define this type constructor
the read and write functions for the Java and IO need to be adapted
to this type so let\textsf{'}s create values of this type and for convenience
we will allocate the buffer inside this function so the read will
take the channel and return a value of the moolaade type so you see
the mana type is this type constructor and I will moon out of a so
we're going to use and I am honored of the pair of bytebuffer an integer
we can use anything as a type parameter why because the idea is that
the continuation monad manages callbacks or consumes callbacks that
will be run on values of type a and so the callback that we had in
the previous code returned an integer or rather it was called on an
integer value and so the byte buffer actually is another useful value
that we want to pass on and so we by using this type we make the API
easier to use so the callbacks in the Java API only take the result
or parameter which is a number of bytes read you are supposed to have
your byte buffers somewhere as global variables it will be much better
if they actually took data here has arguments and that\textsf{'}s what we can
easily accomplish so ni or it will be a function that returns the
Monod type therefore we can use ni or read at the right hand side
of the generator here\textsf{'}s how we do we count as a constructor of the
continuation which takes remember continuation is this type so we
need to create a value of this type in other words we need to write
a function that takes this and returns this so we write a function
that takes this and it returns unit so this entire thing should return
unit Handler is going to be this function because we defined it like
this {[}Music{]} so what does it do well we allocate the buffer for
the purposes of this example I'm cutting all kinds of corners I'm
just allocating a fixed length buffer for its simplicity and I'm ignoring
errors I'm just planting that errors happened all of this can be done
much better with more work so in order to start understanding how
to use it we start with a simple example so we allocate the buffer
then we call the read with this buffer and we make a completion you
know there is no going around this API but we only are going to do
it once and it\textsf{'}s going to be much easier to understand nothing will
be invested callbacks so the failed way ignore the completed log print
something then we do all this rewinding the buffer closing the channel
and then we call the handler on the data that we obtained on the buffer
and the number of bytes read so that\textsf{'}s the call that will return unit
remember so the handler is a callback that returns unit we can actually
rename this for clarity make it call back and so we call this callback
at the end giving it the results we obtained that is what a value
of this type can do it can take this callback produce some values
of type a and call the callback on this value so in our case is just
one value we're not going to call it ever in case of error we do exactly
the same thing for the right now the right method needs a buffer and
the channel has two arguments and it returns them an IO monad of integer
so that\textsf{'}s very similar let\textsf{'}s also rename this handler to callback
consistency and it\textsf{'}s exactly the same thing so check close the channel
and call the results so now let\textsf{'}s see how this is going to be used
we open the channel to the file can then we start writing the for
yield or the function block we do read the result is a pair of buffer
and result then we'll make another channel we do a write with this
buffer and this channel that\textsf{'}s a result we make another channel we
do a read of that channel into a buffer to err is not three when we
compute this is identical if the number of bytes the same and the
string in the buffer is the same after copying and we return or yield
rather is identical in other words this is a boolean value our entire
for yield gives us an enablement of boolean so this is a non-standard
container so none of this actually has been run yet when we do this
when we make this value none of those operations have been done yet
we need to run the bonnet in order to run it but how do we run it
well the run means that we take a value of this type and provided
with an argument of this type and applied that function to that argument
so we need to provide a callback of type a to unit where a is boolean
because we returned it and I have one of the boolean so we need to
provide a callback from boolean to unit let\textsf{'}s provide it so the status
is boolean so it\textsf{'}s a function from Wooyoung to unit so whatever we
want we can put in here and then we run that\textsf{'}s what\textsf{'}s going to print
and it does print exactly what we want at this point now just one
little remark here you see declaration is never used indeed we never
used this value it is returned so to speak but it\textsf{'}s not used that\textsf{'}s
just put an underscore here that is the usual way that we indicate
that there is a value but we don't need it and we put underscore over
there it\textsf{'}s alright so that\textsf{'}s how now our code has become flat in a
sense there is no nested anything there is a bit of there wasn't a
here because of all these options and so on well you can always refactor
that to be some function somewhere else but basically you you can
combine callbacks very easily like this now nothing is so so hard
to understand except for the type of this thing continuation or not
the type of the continuation well that is hard to understand have
to go through the steps it\textsf{'}s a callback consumer that will call the
call back when the value is available and that\textsf{'}s what the ROM does
and you need to understand that flatmap does the same thing so yeah
by the way the implementation of flatmap for my continuation that\textsf{'}s
automated that\textsf{'}s done by the Curie Harvard library all right let me
go back to my slides there\textsf{'}s a last example which is a statement a
statement is defined as this type and it\textsf{'}s used for doing a sequence
of steps that update some state along the way so each of these steps
is a computation that returns some result but also it has a side effect
of updating some state so recall this idea that single value monads
are are containers that hold one value and have a context so the context
for the state model is this state which is a value of type s as a
fixed type the type a is a type parameter of the container but the
state the state value S is a fixed type and the context consists of
this state and of the fact that you can update it as you go so you
can change it and this is the type constructor again just like continuation
it\textsf{'}s not easy to understand why it must be like this I will talk about
this a little later at first let\textsf{'}s see how it works so one good example
of using the state monad is to implement a random number generator
so a random number generator were more stood more precisely a pseudo-random
number generator has an internal state that is updated every time
you ask it for a new random number so it gives you a result which
is a random number but at the same time it updates its internal state
so state monad allows you to do that in a pure functional way without
any mutability and also it has the same advantages as other moments
that you can combine things much easier so without using the state
moment how will we do this so imagine that all the functions are already
implemented so here\textsf{'}s how the PCG random is a very little package
that I wrote it\textsf{'}s has an initial state so the state is some values
initial default state or you can seed it with some other value you
want and then it has a function which I called in 32 that takes the
initial state and returns a pair of some value and a new state then
you would have to call this function again with this new state and
get some random value Y and a state as two now you have to call it
again with s2 and get Z and s 3 and so on so you would have to yourself
keep track of these s0 here as near here as 1 here as 1 here as 3
as 2 here is 2 here and so and if you make a mistake it\textsf{'}s very easy
to make a mistake the types are not going to help you avoid this mistake
if you here say as instead of this one the type is still the same
compiler would not the compiler will not notice so that is error-prone
and ugly the state monad hides this so it hides this as they say threading
of the state for putting you know keeping track of this new state
every time here\textsf{'}s how so in 32 is a function that takes internal state
and returns a tuple of internal state an empty out so actually I need
to interchange the order of these things just for clarity in 32 returns
a pair of {[}Music{]} internal state and a random integer so R\&D
is going to be the type that is a state monad so this is going to
be the factor in the factor block orangie and here\textsf{'}s how we can use
it now look at this code the state is magically handled all we do
is as if we just have a random number function that gets us a new
integer and this is defined here so it\textsf{'}s a constructor of the state
monad which has this type which was asked to escape and this is exactly
the type signature of this function s 2 s so this is the result the
result will be an already of string well you see orangie of in doesn't
mean that it\textsf{'}s a random integer this is a constructor this is a functor
the type of the value inside the furniture can be anything doesn't
have to be random the randomness is only in this piece that returns
random integers once you have those into you can make doubles out
of them course and whatever you want restraining assaulted them so
just to warn you what looked confused that somehow this type constructor
itself makes everything random inside it no it doesn't this is just
a statement it it just takes care of the state and that\textsf{'}s how you
use it now you actually have to run I'm using the cat\textsf{'}s State Mona
which has it\textsf{'}s only POA has a run so you have to run it on initial
state and then the result will be something of which you need to get
a value and then that will be a tuple of state and result so you take
a second part of the tuple and that\textsf{'}s your result so that\textsf{'}s the API
of cats state monad and you do this only once anyway you usually accumulate
a state value combine them together it\textsf{'}s very easy to combine because
monads are easy to combine you can put a state value on the right-hand
side of a generative area you have combines them just like we did
here so once you're ready to run them you perform the run and get
all of this done so just like the other non-standard containers computing
this value does not actually run any of these computations it creates
a function that will run the computations this function still needs
to be called and that call is usually called as usually run the run
method so now we have seen how these different non-standard containers
are used and in what sense they can be interpreted as containers that
hold one value together with a context or how they perform computations
in a context in this slide I will try to motivate why these types
must be like that you see for the writer maybe you understand why
it must be like this we need to log some information so let\textsf{'}s just
put this information into this type here but for these especially
these this is kind of clear you either have a value that\textsf{'}s already
computed or it\textsf{'}s postponed these types are far from clear why are
they like this why do these types embody what they do so here is how
I could kind of derive or motivate from first principles the choice
of these type constructors the main principle here is that we want
to use flatmap in order to chain computations together and so flatmap
is the function that\textsf{'}s going to be transforming some previous values
to some next values in this chain of computations so let\textsf{'}s apply this
reasoning and see what is the signal type signature of flatmap and
just by type reasoning we will derive the correct types start with
the writer monad so the this computation and there\textsf{'}s some information
about it the code we would write would be that first we have some
value of type a would say some X of type a and we transform it into
some f of X of type B so that\textsf{'}s our computation that goes from A to
B at the same time we compute some login information of type W using
the X so what we have here in other words is a pair of functions one
from A to B and one from a to W that is the kind of single step computation
that we want to chain together so these are the things that we want
to change our flat map should take this as its argument because our
principle is that we want to make it into a chain of flat Maps so
in other words this type must be the type of the argument of flat
map but we know that flat map has a type signature which looks like
this from a to writer B right so in other word more precisely the
argument of flat map has this type the flat map has an argument of
this type and it returns a writing B it has an argument of type writer
a an argument of this type and it returns Rho B so writer a yes we
already have writer a always as the first argument so in other words
this type must be the same as this if that is so we would be able
to use flat map to chain computations what is the type writer be so
that this type is equivalent to this one in order to decide type equivalence
we need to use the arithmetic very hard correspondence as I called
it in this correspondence the function types corresponds to miracle
powers so A to B corresponds to B to the power a a to W corresponds
to table to the power a and product is product now using school level
algebra we can simplify this and we say it\textsf{'}s like this it\textsf{'}s the identity
and by the arithmetic correspondence this is also the type equivalence
and so this is a type from a to product of BW and so from a to product
of BW hence writer B must be productive BW so in this way we derived
what the type of writer must be let\textsf{'}s apply the same reasoning to
the other units the reader for example we want to read only context
or environment of type B so what is an elementary step in the computation
we have some X of type a and we compute some value of type B but we
can use this R which is the read-only environment of type e in other
words our type of the elementary step on the computation is this we
repeat the same reason if we want to chain these computations using
flatmap it means that the argument of flatmap must be of this type
but the argument of flatmap is of this type in order to do that we
must have that these types are equivalent this can be done when reader
is the function it to be again we use the arithmetic very hard correspondence
this type is B to the power of product AE so this is just algebraic
notation in a usual arithmetic I shouldn't say algebraic arithmetic
notation this is just B to the power of a times e which represents
this type and what we want is that this is something to the power
a and so this is B to the e to the power a therefore we have the type
e B so again a function type e to B is represented as B to the power
E with reversing the order of this that is how the arithmetic Harvard
correspondence works for function types I discussed this in the third
chapter of the functional programming tutorial look at the continuation
what not now the continuation monad or a call back unit if you wish
it\textsf{'}s a computation that registers a call back that will be called
asynchronously asynchronously means it will be cold later at some
later time or maybe not at all or maybe once or more than once what
is the computation of this kind we take an X of type a and we call
some function on the call back so what does it mean to register a
callback we need to prepare some callback and pass it to somebody
now this is the somebody who will take our callback and they will
return a unit usually I mean they're not going to call the callback
right away anyway so that so this function of registering the callback
normally returns a unit well it could return a different type let\textsf{'}s
say indicating some error in registering the callback but let\textsf{'}s suppose
for simplicity it returns unit so the callback is of this type because
usually callbacks also return unit so what is the type of this elementary
step the type is this it\textsf{'}s from a to a function f that takes a callback
and returns unit so if this function head type eight account B we
would be able to use it in a flat map well this is clear can be must
be this and we can generalize this to return a non unit result type
in case that this should return some kind of result may be error messages
or something else a callback could return more information than just
unit so maybe there\textsf{'}s some error maybe some other other information
so usually the continuation mullet therefore is defined as this type
where ere R where R is a fixed result type finally let\textsf{'}s look at the
state monad state monad is a computation that can update the state
while producing a result so what does it mean such a computation looks
like this first we take some X of type a we take the previous state
of type s and we produce some new value of type B using those two
at the same time we produce a new value of type s from the previous
{[}Music{]} from the previous state so we at the same time change
the state and we compute a new value and while we are computing a
new value we can use the old state and while we're changing the state
we can use the value X that was given to us therefore the type of
the elementary computation step is actually this it\textsf{'}s a pair of two
functions from a and s to B and from a and s to s so the first function
computes a new result and the second function computes a new state
value we now we repeat the same argument this type must be the type
of the argument of flatmap in other words so what is state B if this
type must be equivalent to this let\textsf{'}s make a computation we again
use the Curie Howard correspondence this type corresponds to this
expression we wanted to be something to the power a in order to reduce
it to this form so we transform it like this something to the power
a and we can also simplify it like this something to the power in
translating back to types it means that this type is equivalent to
this in other words a going to this or more simply this so state B
is the type that must be this so we have derived the type constructors
for the monads from first principles just the principle was we have
some elementary step of computation that deals with some kind of context
together with a new value and we want this elementary step of the
computation to be usable under flatmap in other words the type of
this elementary step of the computation must be of the kind a to FB
where F is the function that is the type of the argument of want map
so systematically we demanded that the type was of that kind and that
allowed us straightforwardly to derive the types of these moments
you need to get used to these moments in order to be proficient with
them but I hope that this derivation kind of lifts the veil of mystery
from the question of why are the types of that\textsf{'}s chosen like this
and what is this context and they manipulate here are some exercises
for you to get more familiar with using walnuts and to implement simple
examples using set sequence future lists or try and state units as
well as implementing semi modded instances which means simply implementing
flatmap for certain type instructors that concludes part 1 of chapter
7
\end{comment}


\section{Laws of semimonads and monads}

\subsection{Intuition behind the semimonad laws}

This chapter introduced semimonads to encode nested iteration as functor
block programs with multiple source lines. What properties do we intuitively
expect such programs to have?

When functor blocks describe iterations over data collections, a source
line \lstinline!x <- c! means that the value of \lstinline!x! iterates
over items in the collection \lstinline!c!. An assignment line \lstinline!y = f(x)!
means that we define a local variable \lstinline!y! to equal the
expression \lstinline!f(x)!. We expect to get the same result by
iterating over a collection \lstinline!c! whose values \lstinline!x!
were replaced by \lstinline!f(x)!, i.e., by iterating over \lstinline!c.map(f)!.
It means that the following two code fragments should always give
the same results:

\vspace{0.3\baselineskip}

\noindent \texttt{\textcolor{blue}{\footnotesize{}}}%
\begin{minipage}[c]{0.475\columnwidth}%
\begin{lstlisting}
val result1 = for {
  x <- c
  y = f(x)
  z <- g(y) // Same as z <- g(f(x)).
} yield z
 // Translating the functor block into methods:
val result1 = c.flatMap(x => g(f(x)))
\end{lstlisting}
%
\end{minipage}\texttt{\textcolor{blue}{\footnotesize{}\hspace*{\fill}}}%
\begin{minipage}[c]{0.475\columnwidth}%
\begin{lstlisting}
val result2 = for {
  y <- c.map(x =>
                 f(x))
  z <- g(y) // This code is unchanged.
 } yield z
 // Translating the functor block into methods:
val result2 = c.map(f).flatMap(y => g(y))
\end{lstlisting}
%
\end{minipage}{\footnotesize\par}

\vspace{0\baselineskip}

In the code just shown, an assignment line \lstinline!y = f(x)! occurs
before the last source line \lstinline!z <- p(y)!. The other possibility
is when the assignment line occurs \emph{after} the last source line.
A similar reasoning gives the requirement of equality between these
two code fragments:

\vspace{0.3\baselineskip}

\noindent \texttt{\textcolor{blue}{\footnotesize{}}}%
\begin{minipage}[c]{0.475\columnwidth}%
\begin{lstlisting}
val result1 = for {
  x <- c
  z <- f(x)
  y = g(z)
} yield y
 // Translating the functor block into methods:
val result1 = c.flatMap(f).map(g)
\end{lstlisting}
%
\end{minipage}\texttt{\textcolor{blue}{\footnotesize{}\hspace*{\fill}}}%
\begin{minipage}[c]{0.475\columnwidth}%
\begin{lstlisting}
val result2 = for {
  x <- c
  y <- f(x).map(z =>
                    g(z))
 } yield y
 // Translating the functor block into methods:
val result2 = c.flatMap { x => f(x).map(g) }
\end{lstlisting}
%
\end{minipage}\vspace{0\baselineskip}

Now consider the case when there are more than two levels of nested
iterations. Such programs are usually written as functor blocks with
three or more source lines. However, any subgroup of source lines
can be refactored into a separate functor block with unchanged result:

\vspace{0.3\baselineskip}

\noindent \texttt{\textcolor{blue}{\footnotesize{}}}%
\begin{minipage}[c]{0.475\columnwidth}%
\begin{lstlisting}
val result1 = for {
  x <- c
  y <- f(x)
  z <- g(y)
} yield z
 // Translating the functor block into methods:
val result1 = c.flatMap{ x => f(x).flatMap(g) }
\end{lstlisting}
%
\end{minipage}\texttt{\textcolor{blue}{\footnotesize{}\hspace*{\fill}}}%
\begin{minipage}[c]{0.475\columnwidth}%
\begin{lstlisting}
val result2 = for {
  yy <- for { x <- c
              y <- f(x) } yield y
  z  <- g(yy)
 } yield z
 // Translating the functor block into methods:
val result2 = c.flatMap(f).flatMap(yy => g(yy))
\end{lstlisting}
%
\end{minipage}\vspace{0\baselineskip}

We obtained three general requirements (or \textsf{``}laws\textsf{''}) for the \lstinline!flatMap!
method. Let us now formulate these requirements as rigorous equations.

For brevity, we will denote the \lstinline!flatMap! method for a
semimonad \lstinline!S[_]! by \textsf{``}$\text{flm}$\textsf{''}. We will write
$\text{flm}_{S}$ when we need to indicate explicitly the type constructor
being used. The type signature is

\begin{wrapfigure}{l}{0.5\columnwidth}%
\vspace{-0.9\baselineskip}

\begin{lstlisting}
def flm[A, B](f: A => S[B]): S[A] => S[B] 
\end{lstlisting}

\vspace{-0.5\baselineskip}
\end{wrapfigure}%

~\vspace{-0.5\baselineskip}
\[
\text{flm}^{A,B}:(A\rightarrow S^{B})\rightarrow S^{A}\rightarrow S^{B}\quad.
\]

The first law is written in Scala code as

\begin{wrapfigure}{l}{0.4\columnwidth}%
\vspace{-0.75\baselineskip}

\begin{lstlisting}
c.flatMap(x => g(f(x))) ==
                    c.map(f).flatMap(g)
\end{lstlisting}
\vspace{0.2\baselineskip}
\[
\xymatrix{\xyScaleY{0.2pc}\xyScaleX{3pc} & S^{B}\ar[rd]\sp(0.5){~~\ \text{flm}\,(g^{:B\rightarrow S^{C}})}\\
S^{A}\ar[ru]\sp(0.5){f^{\uparrow S}}\ar[rr]\sb(0.5){\text{flm}\,(f^{:A\rightarrow B}\bef\,g^{:B\rightarrow S^{C}})\,} &  & S^{C}
}
\]

\vspace{-0.6\baselineskip}
\end{wrapfigure}%

\noindent In the code notation, we omit the argument \lstinline!c!
(that is, we are using the point-free style) and write the law as

\begin{equation}
\text{flm}\,(f^{:A\rightarrow B}\bef g^{:B\rightarrow S^{C}})=f^{\uparrow S}\bef\text{flm}\,(g)\quad.\label{eq:left-naturality-law-flatMap}
\end{equation}

\noindent This equation holds for arbitrary $f^{:A\rightarrow B}$
and $g^{:B\rightarrow S^{C}}$. This is a \textsf{``}\textbf{left naturality}
law\index{naturality law!of flatMap@of \texttt{flatMap}} of \lstinline!flatMap!\textsf{''}
since it exchanges the order of lifted functions to the left of \lstinline!flatMap!.
More precisely, we may call this equation the naturality law of \lstinline!flatMap[A, B]!
\textsf{``}with respect to \lstinline!A!\textsf{''} since the application of $f^{\uparrow S}$
acts on the type parameter \lstinline!A!.

The second law holds for arbitrary $f^{:A\rightarrow S^{B}}$ and
$g^{:B\rightarrow C}$:

\begin{wrapfigure}{l}{0.4\columnwidth}%
\vspace{-0.75\baselineskip}

\begin{lstlisting}
c.flatMap(f).map(g) ==
         c.flatMap { x => f(x).map(g) }
\end{lstlisting}
\vspace{0.2\baselineskip}
\[
\xymatrix{\xyScaleY{0.2pc}\xyScaleX{3pc} & S^{B}\ar[rd]\sp(0.5){\ \,(g^{:B\rightarrow C})^{\uparrow S}}\\
S^{A}\ar[ru]\sp(0.5){\text{flm}\,(f^{:A\rightarrow S^{B}})~~~}\ar[rr]\sb(0.5){\text{flm}\,(f^{:A\rightarrow S^{B}}\bef\,g^{\uparrow S})\,} &  & S^{C}
}
\]

\vspace{-0.2\baselineskip}
\end{wrapfigure}%

\noindent \vspace{-0.35\baselineskip}
\begin{equation}
\text{flm}\,(f^{:A\rightarrow S^{B}}\bef g^{\uparrow S})=\text{flm}\,(f)\bef g^{\uparrow S}\quad.\label{eq:right-naturality-law-flatMap}
\end{equation}

\noindent This is a \index{naturality law!of flatMap@of \texttt{flatMap}}\textbf{right
naturality} law or \textsf{``}naturality with respect to \lstinline!B!\textsf{''}
of \lstinline!flatMap[A, B]!: it manipulates a lifted function $g^{\uparrow S}$
to the right of \lstinline!flatMap!, acting on the type parameter
\lstinline!B!.

The third law relates nested \lstinline!flatMap! operations:

\begin{wrapfigure}{l}{0.4\columnwidth}%
\vspace{-0.6\baselineskip}

\begin{lstlisting}
c.flatMap { x => f(x).flatMap(g) } ==
                c.flatMap(f).flatMap(g)
\end{lstlisting}
\vspace{0\baselineskip}
\[
\xymatrix{\xyScaleY{0.2pc}\xyScaleX{3pc} & S^{B}\ar[rd]\sp(0.5){~\ \text{flm}\,(g^{:B\rightarrow S^{C}})}\\
S^{A}\ar[ru]\sp(0.5){\text{flm}\,(f^{:A\rightarrow S^{B}})~~\ }\ar[rr]\sb(0.5){\text{flm}\,(f^{:A\rightarrow S^{B}}\bef\,\text{flm}\,(g))\,} &  & S^{C}
}
\]

\vspace{0.6\baselineskip}
\end{wrapfigure}%
~\vspace{-1.6\baselineskip}

\begin{equation}
\text{flm}\,\big(f^{:A\rightarrow S^{B}}\bef\text{flm}\,(g^{:B\rightarrow S^{C}})\big)=\text{flm}\left(f\right)\bef\text{flm}\left(g\right)\quad.\label{eq:associativity-law-flatMap}
\end{equation}

\vspace{-0.2\baselineskip}

This equation is called the \textbf{associativity law}\index{associativity law!of flatMap@of \texttt{flatMap}}
of \lstinline!flatMap!, for reasons we will fully explore below.

The three laws of semimonads express a programmer\textsf{'}s intuitive reasoning
about code. If a monad\textsf{'}s implementation does not obey one of these
laws, programs written with that monad may give wrong results even
though the code looks correct. To avoid those hard-to-debug errors,
we must verify that the code for every monad\textsf{'}s \lstinline!flatMap!
method obeys the laws. 

At this point, the three laws of semimonads may appear complicated
and hard to understand and to verify. In the next subsections, we
will derive a shorter and clearer formulation of those laws. For now,
let us define a \lstinline!Semimonad! typeclass\index{typeclass!Semimonad@\texttt{Semimonad}}
and test the laws using the \texttt{scalacheck} library:
\begin{lstlisting}
abstract class Semimonad[F[_]: Functor] {
  def flatMap[A, B](fa: F[A])(f: A => F[B]): F[B]
}
implicit class SemimonadOps[F[_]: Semimonad, A](fa: F[A]) { // Define flatMap as an extension method.
  def flatMap[B](f: A => F[B]): F[B] = implicitly[Semimonad[F]].flatMap(fa)(f)
}
def checkSemimonadLaws[F[_], A, B, C]()(implicit ff: Semimonad[F],   // Use the `Arbitrary` typeclass
   fa: Arbitrary[F[A]], ab: Arbitrary[A => F[B]], bc: Arbitrary[B => F[C]]) = { // from `scalacheck`.
    forAll { (f: A => F[B], g: B => F[C], fa: F[A]) =>               // Associativity law of flatMap.
      fa.flatMap(x => f(x).flatMap(g)) shouldEqual fa.flatMap(f).flatMap(g)
    }
} // Assuming that a Semimonad instance was defined for Seq[_], check the laws with specific A, B, C.
checkSemimonadLaws[Seq, Int, String, Double]()
\end{lstlisting}


\subsection{The laws of \texttt{flatten}}

In Section~\ref{subsec:Simplifying-the-filtering-laws-deflate} we
simplified the laws of the \lstinline!filter! operation by passing
to a simpler \lstinline!deflate! function. We then showed that these
two functions are equivalent if certain laws are assumed to hold for
\lstinline!filter!. We will now derive a similar relationship between
the methods \lstinline!flatMap! and \lstinline!flatten!. We will
see that \lstinline!flatten! has fewer laws, and that its laws are
simpler to verify.

\subsubsection{Statement \label{subsec:Statement-flatten-equivalent-to-flatMap}\ref{subsec:Statement-flatten-equivalent-to-flatMap}}

The type of the method \lstinline!flatten! (denoted by $\text{ftn}^{A}:S^{S^{A}}\rightarrow S^{A}$)
is equivalent\index{type equivalence!examples} to the type of \lstinline!flatMap!
as long as \lstinline!flatMap! satisfies its left naturality law~(\ref{eq:left-naturality-law-flatMap}).

\subparagraph{Proof}

By definition, \lstinline!flatMap! is expressed as a composition
of \lstinline!map! and \lstinline!flatten!,

\begin{wrapfigure}{l}{0.4\columnwidth}%
\vspace{-0.85\baselineskip}

\begin{lstlisting}
c.flatMap(f) == c.map(f).flatten
\end{lstlisting}
\vspace{0.2\baselineskip}
\[
\xymatrix{\xyScaleY{0.3pc}\xyScaleX{3.5pc} & S^{S^{B}}\ar[rd]\sp(0.5){\ \text{ftn}\ }\\
S^{A}\ar[ru]\sp(0.5){(f^{:A\rightarrow S^{B}})^{\uparrow S}\ }\ar[rr]\sp(0.5){\text{flm}\,(f^{:A\rightarrow S^{B}})\,} &  & S^{B}
}
\]

\vspace{1.3\baselineskip}
\end{wrapfigure}%

~\vspace{-1.5\baselineskip}

\[
\text{flm}_{S}(f)=f^{\uparrow S}\bef\text{ftn}_{S}\quad.
\]

\noindent Substituting $f\triangleq\text{id}^{:S^{A}\rightarrow S^{A}}$
into this equation, we get
\[
\text{flm}\left(\text{id}\right)=\gunderline{\text{id}^{\uparrow S}}\bef\text{ftn}=\text{ftn}\quad.
\]
This expresses \lstinline!flatten! through \lstinline!flatMap!.
It remains to show that the relationship between \lstinline!flatten!
and \lstinline!flatMap! is an isomorphism. For that, we need to prove
two properties:

(1) Starting with a given function $\text{ftn}:S^{S^{A}}\rightarrow S^{A}$,
define $\text{flm}\left(f\right)\triangleq f^{\uparrow S}\bef\text{ftn}$
and then define a new function $\text{ftn}^{\prime}\triangleq\text{flm}\left(\text{id}\right)$.
Prove that $\text{ftn}^{\prime}=\text{ftn}$:
\[
\text{ftn}^{\prime}=\text{flm}\left(\text{id}\right)=\gunderline{\text{id}^{\uparrow S}}\bef\text{ftn}=\text{id}\bef\text{ftn}=\text{ftn}\quad.
\]
If \lstinline!flatMap! is defined via \lstinline!flatten!, the left
naturality law of \lstinline!flatMap! is automatically satisfied:
\begin{align*}
{\color{greenunder}\text{expect to equal }\text{flm}\left(f\bef g\right):}\quad & f^{\uparrow S}\bef\text{flm}\left(g\right)=\gunderline{f^{\uparrow S}\bef g^{\uparrow S}}\bef\text{ftn}\\
{\color{greenunder}\text{composition law of }S:}\quad & =(f\bef g)^{\uparrow S}\bef\text{ftn}=\text{flm}\left(f\bef g\right)\quad.
\end{align*}

(2) Starting with a given function $\text{flm}$ that satisfies the
left naturality law, define $\text{ftn}\triangleq\text{flm}\left(\text{id}\right)$
and then define a new function $\text{flm}^{\prime}\left(f\right)\triangleq f^{\uparrow S}\bef\text{ftn}$.
Prove that $\text{flm}^{\prime}=\text{flm}$:
\begin{align*}
{\color{greenunder}\text{expect to equal }\text{flm}\left(f\right):}\quad & \text{flm}^{\prime}\left(f\right)=f^{\uparrow S}\bef\text{ftn}=f^{\uparrow S}\bef\text{flm}\left(\text{id}\right)\\
{\color{greenunder}\text{left naturality law of }\text{flm}:}\quad & =\text{flm}\left(f\bef\text{id}\right)=\text{flm}\left(f\right)\quad.
\end{align*}


\subsubsection{Statement \label{subsec:Statement-flatten-has-2-laws}\ref{subsec:Statement-flatten-has-2-laws}}

If a \lstinline!flatMap! function satisfies the three laws~(\ref{eq:left-naturality-law-flatMap})\textendash (\ref{eq:associativity-law-flatMap}),
the corresponding \lstinline!flatten! function defined as $\text{ftn}\triangleq\text{flm}\left(\text{id}\right)$
satisfies its \emph{two} laws, with an arbitrary $f^{:A\rightarrow B}$:
\begin{align}
{\color{greenunder}\text{naturality law of }\text{ftn}:}\quad & f^{\uparrow S\uparrow S}\bef\text{ftn}=\text{ftn}\bef f^{\uparrow S}\quad,\label{eq:naturality-law-of-flatten}\\
{\color{greenunder}\text{associativity law of }\text{ftn}:}\quad & \text{ftn}^{\uparrow S}\bef\text{ftn}=\text{ftn}\bef\text{ftn}\quad.\label{eq:associativity-law-of-flatten}
\end{align}
The following type diagrams illustrate these laws:

\vspace{-1.5\baselineskip}
\begin{minipage}[t]{0.45\columnwidth}%
\[
\xymatrix{\xyScaleY{0.2pc}\xyScaleX{5pc} & S^{S^{B}}\ar[rd]\sp(0.5){\ \text{ftn}^{B}}\\
S^{S^{A}}\ar[ru]\sp(0.5){(f^{:A\rightarrow B})^{\uparrow S\uparrow S}\ \ }\ar[rd]\sb(0.5){\text{ftn}^{A}\,} &  & S^{B}\\
 & S^{A}\ar[ru]\sb(0.5){(f^{:A\rightarrow B})^{\uparrow S}}
}
\]
%
\end{minipage}\hfill{}%
\begin{minipage}[t]{0.45\columnwidth}%
\[
\xymatrix{\xyScaleY{0.2pc}\xyScaleX{5pc} & S^{S^{A}}\ar[rd]\sp(0.5){\ \text{ftn}^{A}}\\
S^{S^{S^{A}}}\ar[ru]\sp(0.5){(\text{ftn}^{A})^{\uparrow S}\ }\ar[rd]\sb(0.5){\text{ftn}^{S^{A}}\,} &  & S^{A}\\
 & S^{S^{A}}\ar[ru]\sb(0.5){\text{ftn}^{A}}
}
\]
%
\end{minipage}

Note that the associativity law involves two intermediate values of
type $S^{S^{A}}$ that are \emph{not} necessarily equal. The associativity
law requires only the final results (of type $S^{A}$) to be equal.

\subparagraph{Proof}

By Statement~\ref{subsec:Statement-flatten-equivalent-to-flatMap},
we have $\text{flm}\left(f\right)=f^{\uparrow S}\bef\text{ftn}$ since
it is given that the left naturality law of \lstinline!flatMap! holds.
Substituting that into the other two laws of \lstinline!flatMap!,
we get:
\begin{align*}
{\color{greenunder}\text{right naturality law of }\text{flm}:}\quad & \text{flm}\,\big(f\bef g^{\uparrow S}\big)=\text{flm}\left(f\right)\bef g^{\uparrow S}\quad,\\
{\color{greenunder}\text{substitute \ensuremath{\text{flm}} via }\text{ftn}:}\quad & \big(f\bef g^{\uparrow S}\big)^{\uparrow S}\bef\text{ftn}=f^{\uparrow S}\bef\text{ftn}\bef g^{\uparrow S}\quad,\\
{\color{greenunder}\text{set }f\triangleq\text{id}:}\quad & g^{\uparrow S\uparrow S}\bef\text{ftn}=\text{ftn}\bef g^{\uparrow S}\quad,
\end{align*}
which shows that Eq.~(\ref{eq:naturality-law-of-flatten}) holds;
and finally:
\begin{align*}
{\color{greenunder}\text{associativity law of }\text{flm}:}\quad & \text{flm}\,\big(f\bef\text{flm}\,(g)\big)=\text{flm}\left(f\right)\bef\text{flm}\left(g\right)\quad,\\
{\color{greenunder}\text{substitute \ensuremath{\text{flm}} via }\text{ftn}:}\quad & \big(f\bef g^{\uparrow S}\bef\text{flm}\,(g)\big)^{\uparrow S}\bef\text{ftn}=\big(\gunderline{f\bef g^{\uparrow S}}\bef\text{ftn}\big)^{\uparrow S}\bef\text{ftn}=\gunderline{f^{\uparrow S}}\bef\text{ftn}\bef\gunderline{g^{\uparrow S}}\bef\text{ftn}\quad,\\
{\color{greenunder}\text{set }f\triangleq\text{id}\text{ and }g\triangleq\text{id}:}\quad & \text{ftn}^{\uparrow S}\bef\text{ftn}=\text{ftn}\bef\text{ftn}\quad.
\end{align*}
This verifies Eq.~(\ref{eq:associativity-law-of-flatten}).

\subsubsection{Statement \label{subsec:Statement-flatten-laws-to-flatMap-laws}\ref{subsec:Statement-flatten-laws-to-flatMap-laws}}

If a \lstinline!flatten! function satisfies the laws~(\ref{eq:naturality-law-of-flatten})\textendash (\ref{eq:associativity-law-of-flatten})
then the corresponding \lstinline!flatMap! function defined by $\text{flm}\left(f\right)\triangleq f^{\uparrow S}\bef\text{ftn}$
will satisfy its three laws~(\ref{eq:left-naturality-law-flatMap})\textendash (\ref{eq:associativity-law-flatMap}).

\subparagraph{Proof}

By Statement~\ref{subsec:Statement-flatten-equivalent-to-flatMap},
the left naturality law holds. To check the right naturality law:
\begin{align*}
{\color{greenunder}\text{expect to equal }\text{flm}\left(f\right)\bef g^{\uparrow S}:}\quad & \text{flm}\,\big(f\bef g^{\uparrow S}\big)=\gunderline{\big(f\bef g^{\uparrow S}\big)^{\uparrow S}}\bef\text{ftn}=f^{\uparrow S}\bef\gunderline{g^{\uparrow S\uparrow S}\bef\text{ftn}}\\
{\color{greenunder}\text{naturality law of }\text{ftn}:}\quad & =\gunderline{f^{\uparrow S}\bef\text{ftn}}\bef g^{\uparrow S}=\text{flm}\left(f\right)\bef g^{\uparrow S}\quad.
\end{align*}
To check the associativity law:
\begin{align*}
{\color{greenunder}\text{expect to equal }\text{flm}\left(f\right)\bef\text{flm}\left(g\right):}\quad & \text{flm}\,\big(f\bef\text{flm}\,(g)\big)=\big(f\bef\text{flm}\,(g)\big)^{\uparrow S}\bef\text{ftn}=\big(f\bef g^{\uparrow S}\bef\gunderline{\text{ftn}\big)^{\uparrow S}\bef\text{ftn}}\\
{\color{greenunder}\text{associativity law of }\text{ftn}:}\quad & =f^{\uparrow S}\bef\gunderline{g^{\uparrow S\uparrow S}\bef\text{ftn}}\bef\text{ftn}\\
{\color{greenunder}\text{naturality law of }\text{ftn}:}\quad & =\gunderline{f^{\uparrow S}\bef\text{ftn}}\bef\gunderline{g^{\uparrow S}\bef\text{ftn}}=\text{flm}\left(f\right)\bef\text{flm}\left(g\right)\quad.
\end{align*}
 

We have proved that \lstinline!flatten! is equivalent to \lstinline!flatMap!
but has fewer laws.

By the \index{parametricity theorem}parametricity theorem (see Appendix~\ref{app:Proofs-of-naturality-parametricity}),
any purely functional code will obey naturality laws. All semimonads
and monads in this chapter (except \lstinline!Future!) are purely
functional, so we will not need to verify their naturality laws. However,
verifying the associativity law involves complicated derivations.
Using \lstinline!flatten! instead of \lstinline!flatMap! will often
make those derivations shorter.

\subsection{Verifying the associativity law via \texttt{flatten}}

\begin{comment}
The associativity law of \lstinline!flatMap! was demonstrated to
hold for the \lstinline!Option! monad in Chapter~\ref{chap:Filterable-functors}
(see Eq.~(\ref{eq:associativity-law-of-flatMap-for-Option}) in the
proof of Statement~\ref{subsec:Statement-filterable-coproduct-1}). 
\end{comment}
The following examples will verify the associativity law of \lstinline!flatten!
for some standard monads.

\subsubsection{Example \label{subsec:Example-flatten-verify-for-monad}\ref{subsec:Example-flatten-verify-for-monad}\index{solved examples}}

The standard Scala types \lstinline!Either! and \lstinline!Try!
are examples of the monad $F^{A}\triangleq Z+A$, where $Z$ is a
fixed type. Show that this monad satisfies the associativity law.

\subparagraph{Solution}

The type signature of \lstinline!flatten! is $\text{ftn}:Z+\left(Z+A\right)\rightarrow Z+A$,
and its code is

\begin{wrapfigure}{l}{0.6\columnwidth}%
\vspace{-0.2\baselineskip}
\begin{lstlisting}
def flatten[A]: Either[Z, Either[Z, A]] => Either[Z, A] = {
  case Left(z)           => Left(z)
  case Right(Left(z))    => Left(z)
  case Right(Right(a))   => Right(a)
}
\end{lstlisting}

\vspace{-3.2\baselineskip}
\end{wrapfigure}%

~\vspace{-1.2\baselineskip}
\[
\text{ftn}^{:Z+Z+A\rightarrow Z+A}\triangleq\,\begin{array}{|c||cc|}
 & Z & A\\
\hline Z & \text{id} & \bbnum 0\\
Z & \text{id} & \bbnum 0\\
A & \bbnum 0 & \text{id}
\end{array}\quad.
\]
\vspace{-0.8\baselineskip}

Since \lstinline!flatten! is fully parametric, both sides of the
law are fully parametric functions with the type signature $Z+Z+Z+A\rightarrow Z+A$.
This type signature has \emph{only one} fully parametric implementation:
since it is not possible to produce values of unknown types $A$ and
$Z$ from scratch, an implementation of $Z+Z+Z+A\rightarrow Z+A$
must return $Z+\bbnum 0$ when the input contains a value of type
$Z$; otherwise it must return $\bbnum 0+A$. So, both sides of the
law must have the same code.

To prove rigorously that only one implementation exists, we must use
the Curry-Howard correspondence and a decision algorithm for constructive
logic. Instead, we can verify the associativity law by an explicit
derivation. First, we need to lift \lstinline!flatten! to the functor
$F$. The lifting code is
\[
(f^{:A\rightarrow B})^{\uparrow F}\triangleq\,\begin{array}{|c||cc|}
 & Z & B\\
\hline Z & \text{id} & \bbnum 0\\
A & \bbnum 0 & f
\end{array}\quad,\quad\quad\text{ftn}^{\uparrow F}=\,\begin{array}{|c||ccc|}
 & Z & Z & A\\
\hline Z & \text{id} & \bbnum 0 & \bbnum 0\\
Z & \bbnum 0 & \text{id} & \bbnum 0\\
Z & \bbnum 0 & \text{id} & \bbnum 0\\
A & \bbnum 0 & \bbnum 0 & \text{id}
\end{array}\quad.
\]
For comparison, the Scala code for $\text{ftn}^{\uparrow F}$ (had
we needed to write it) would look like this,
\begin{lstlisting}
def fmapFlatten[A]: Either[Z, Either[Z, Either[Z, A]]] => Either[Z, Either[Z, A]] = {
  case Left(z)                  => Left(z)
  case Right(Left(z))           => Right(Left(z))
  case Right(Right(Left(z)))    => Right(Left(z))
  case Right(Right(Right(a)))   => Right(Right(a))
}
\end{lstlisting}

Now we can compute the two sides of the associativity law~(\ref{eq:associativity-law-of-flatten})
via matrix composition:
\begin{align*}
{\color{greenunder}\text{left-hand side}:}\quad & \text{ftn}^{\uparrow F}\bef\text{ftn}=\,\begin{array}{|c||ccc|}
 & Z & Z & A\\
\hline Z & \text{id} & \bbnum 0 & \bbnum 0\\
Z & \bbnum 0 & \text{id} & \bbnum 0\\
Z & \bbnum 0 & \text{id} & \bbnum 0\\
A & \bbnum 0 & \bbnum 0 & \text{id}
\end{array}\,\bef\,\begin{array}{|c||cc|}
 & Z & A\\
\hline Z & \text{id} & \bbnum 0\\
Z & \text{id} & \bbnum 0\\
A & \bbnum 0 & \text{id}
\end{array}\,=\,\begin{array}{|c||cc|}
 & Z & A\\
\hline Z & \text{id} & \bbnum 0\\
Z & \text{id} & \bbnum 0\\
Z & \text{id} & \bbnum 0\\
A & \bbnum 0 & \text{id}
\end{array}\quad,
\end{align*}
\begin{align*}
{\color{greenunder}\text{right-hand side}:}\quad & \text{ftn}^{:Z+Z+\left(Z+A\right)\rightarrow Z+\left(Z+A\right)}\bef\text{ftn}=\,\begin{array}{|c||cc|}
 & Z & \gunderline{Z+A}\\
\hline Z & \text{id} & \bbnum 0\\
Z & \text{id} & \bbnum 0\\
\gunderline{Z+A} & \bbnum 0 & \gunderline{\text{id}}
\end{array}\,\bef\,\begin{array}{|c||cc|}
 & Z & A\\
\hline Z & \text{id} & \bbnum 0\\
Z & \text{id} & \bbnum 0\\
A & \bbnum 0 & \text{id}
\end{array}\\
{\color{greenunder}\text{expand }\text{id}^{Z+A}:}\quad & \quad=\,\begin{array}{|c||ccc|}
 & Z & Z & A\\
\hline Z & \text{id} & \bbnum 0 & \bbnum 0\\
Z & \text{id} & \bbnum 0 & \bbnum 0\\
Z & \bbnum 0 & \text{id} & \bbnum 0\\
A & \bbnum 0 & \bbnum 0 & \text{id}
\end{array}\,\bef\,\begin{array}{|c||cc|}
 & Z & A\\
\hline Z & \text{id} & \bbnum 0\\
Z & \text{id} & \bbnum 0\\
A & \bbnum 0 & \text{id}
\end{array}=\,\begin{array}{|c||cc|}
 & Z & A\\
\hline Z & \text{id} & \bbnum 0\\
Z & \text{id} & \bbnum 0\\
Z & \text{id} & \bbnum 0\\
A & \bbnum 0 & \text{id}
\end{array}\quad.
\end{align*}
The two sides of the associativity law are equal.

When it works, the technique of Curry-Howard code inference\index{code inference}
gives much shorter proofs than explicit derivations:

\subsubsection{Example \label{subsec:Example-flatten-verify-for-monad-1}\ref{subsec:Example-flatten-verify-for-monad-1}}

Verify that the \lstinline!Reader! monad, $F^{A}\triangleq Z\rightarrow A$,
satisfies the associativity law.

\subparagraph{Solution}

The type signature of \lstinline!flatten! is $\left(Z\rightarrow Z\rightarrow A\right)\rightarrow Z\rightarrow A$.
Both sides of the law~(\ref{eq:associativity-law-of-flatten}) are
functions with the type signature $(Z\rightarrow Z\rightarrow Z\rightarrow A)\rightarrow Z\rightarrow A$.
By code inference with typed holes, we find that there is only one
fully parametric implementation of this type signature, namely
\[
p^{:Z\rightarrow Z\rightarrow Z\rightarrow A}\rightarrow z^{:Z}\rightarrow p(z)(z)(z)\quad.
\]
So, both sides of the law must have the same code, and the law holds.

\subsubsection{Example \label{subsec:Example-flatten-verify-for-monad-1-1}\ref{subsec:Example-flatten-verify-for-monad-1-1}}

Show that the \lstinline!List! monad ($F^{A}\triangleq\text{List}^{A}$)
satisfies the associativity law.

\subparagraph{Solution}

The \lstinline!flatten[A]! method has the type signature $\text{ftn}^{A}:\text{List}^{\text{List}^{A}}\rightarrow\text{List}^{A}$
and concatenates the nested lists in their order. Let us first show
a more visual (but less formal) proof of the associativity law. Both
sides of the law are functions of type $\text{List}^{\text{List}^{\text{List}^{A}}}\rightarrow\text{List}^{A}$.
We can visualize how both sides of the law are applied to a triple-nested
list value $p$ defined by
\[
p\triangleq\left[\left[\left[x_{11},x_{12},...\right],\left[x_{21},x_{22},...\right],...\right],\left[\left[y_{11},y_{12},...\right],\left[y_{21},y_{22},...\right],...\right],...\right]\quad,
\]
where all $x_{ij}$, $y_{ij}$, $...$ have type $A$. Applying $\text{ftn}^{\uparrow\text{List}}$
flattens the inner lists and produces
\[
p\triangleright\text{ftn}^{\uparrow\text{List}}=\left[\left[x_{11},x_{12},...,x_{21},x_{22},...\right],\left[y_{11},y_{12},...,y_{21},y_{22},...\right],...\right]\quad.
\]
Flattening that result gives a list of all values $x_{ij}$, $y_{ij}$,
..., in the order they appear in $p$:
\[
p\triangleright\text{ftn}^{\uparrow\text{List}}\triangleright\text{ftn}=\left[x_{11},x_{12},...,x_{21},x_{22},...,y_{11},y_{12},...,y_{21},y_{22},...,...\right]\quad.
\]
Applying $\text{ftn}^{\text{List}^{A}}$ to $p$ will flatten the
outer lists,
\[
p\triangleright\text{ftn}^{\text{List}^{A}}=\left[\left[x_{11},x_{12},...\right],\left[x_{21},x_{22},...\right],...,\left[y_{11},y_{12},...\right],\left[y_{21},y_{22},...\right],...\right]\quad.
\]
Flattening that value results in $p\triangleright\text{ftn}^{\text{List}^{A}}\triangleright\text{ftn}=\left[x_{11},x_{12},...,x_{21},x_{22},...,y_{11},y_{12},...,y_{21},y_{22},...,...\right]$.
This is exactly the same as $p\triangleright\text{ftn}^{\uparrow\text{List}}\triangleright\text{ftn}$:
namely, the list of all values in the order they appear in $p$.

Let us now prove the associativity law by an explicit derivation.
Using the recursive type definition $\text{List}^{A}\triangleq\bbnum 1+A\times\text{List}^{A}$,
we can define \lstinline!flatten! as a recursive function:
\[
\text{ftn}^{A}\triangleq\,\begin{array}{|c||c|}
 & \bbnum 1+\text{List}^{A}\times\text{List}^{\text{List}^{A}}\\
\hline \bbnum 1 & 1\rightarrow1+\bbnum 0\\
\text{List}^{A}\times\text{List}^{\text{List}^{A}} & h^{:\text{List}^{A}}\times t^{:\text{List}^{\text{List}^{A}}}\rightarrow h\pplus(t\triangleright\overline{\text{ftn}})
\end{array}\quad,
\]
where we have used the function \lstinline!concat! (denoted $\pplus$)
whose associativity property was derived in Statement~\ref{subsec:Statement-concat-array-associativity}.
The operation of lifting to the \lstinline!List! functor is defined
for arbitrary functions $f$ by
\[
(f^{:A\rightarrow B})^{\uparrow\text{List}}\triangleq\,\begin{array}{|c||cc|}
 & \bbnum 1 & B\times\text{List}^{B}\\
\hline \bbnum 1 & \text{id} & \bbnum 0\\
A\times\text{List}^{A} & \bbnum 0 & h^{:A}\times t^{:\text{List}^{A}}\rightarrow f(h)\times\big(t\triangleright f^{\overline{\uparrow\text{List}}}\big)
\end{array}\quad.
\]
The proof is by induction; the overline denotes recursive function
calls, for which all laws hold by inductive assumption. We write the
code for $\text{ftn}^{\uparrow\text{List}}$ and $\text{ftn}^{\text{List}^{A}}$,
both of type $\text{List}^{\text{List}^{\text{List}^{A}}}\rightarrow\text{List}^{\text{List}^{A}}$:
\begin{align*}
\text{ftn}^{\uparrow\text{List}} & =\,\begin{array}{|c||cc|}
 & \bbnum 1 & \text{List}^{A}\times\text{List}^{\text{List}^{A}}\\
\hline \bbnum 1 & \text{id} & \bbnum 0\\
\text{List}^{\text{List}^{A}}\times\text{List}^{\text{List}^{\text{List}^{A}}} & \bbnum 0 & h^{:\text{List}^{\text{List}^{A}}}\times t^{:\text{List}^{\text{List}^{\text{List}^{A}}}}\rightarrow\text{ftn}\,(h)\times\big(t\triangleright\text{ftn}^{\overline{\uparrow\text{List}}}\big)
\end{array}\quad,\\
\text{ftn}^{\text{List}^{A}} & =\,\,\begin{array}{|c||c|}
 & \bbnum 1+\text{List}^{A}\times\text{List}^{\text{List}^{A}}\\
\hline \bbnum 1 & 1\rightarrow1+\bbnum 0\\
\text{List}^{\text{List}^{A}}\times\text{List}^{\text{List}^{\text{List}^{A}}} & h^{:\text{List}^{\text{List}^{A}}}\times t^{:\text{List}^{\text{List}^{\text{List}^{A}}}}\rightarrow h\pplus\big(t\triangleright\overline{\text{ftn}}^{\text{List}^{A}}\big)
\end{array}\quad.
\end{align*}
It remains to compute $\text{ftn}^{\uparrow\text{List}}\bef\text{ftn}^{A}$
and $\text{ftn}^{\text{List}^{A}}\bef\text{ftn}^{A}$ via matrix composition.
The first one is quick:
\begin{align*}
 & \text{ftn}^{\uparrow\text{List}}\bef\text{ftn}^{A}=\,\begin{array}{||cc|}
\text{id} & \bbnum 0\\
\bbnum 0 & h\times t\rightarrow\text{ftn}\,(h)\times\big(t\triangleright\text{ftn}^{\overline{\uparrow\text{List}}}\big)
\end{array}\,\bef\,\begin{array}{||c|}
1\rightarrow1+\bbnum 0\\
h\times t\rightarrow h\pplus(t\triangleright\overline{\text{ftn}})
\end{array}\\
 & \quad=\,\begin{array}{|c||c|}
 & \bbnum 1+A\times\text{List}^{A}\\
\hline \bbnum 1 & 1\rightarrow1+\bbnum 0\\
\text{List}^{\text{List}^{A}}\times\text{List}^{\text{List}^{\text{List}^{A}}} & h\times t\rightarrow\text{ftn}\,(h)\pplus\big(t\triangleright\text{ftn}^{\overline{\uparrow\text{List}}}\triangleright\overline{\text{ftn}}\big)
\end{array}\quad.
\end{align*}
The second calculation gets stuck because the code matrix for $\text{ftn}^{\text{List}^{A}}$
has an unsplit column:
\[
\text{ftn}^{\text{List}^{A}}\bef\text{ftn}^{A}=\,\begin{array}{|c||c|}
 & \bbnum 1+\text{List}^{A}\times\text{List}^{\text{List}^{A}}\\
\hline \bbnum 1 & 1\rightarrow1+\bbnum 0\\
\text{List}^{\text{List}^{A}}\times\text{List}^{\text{List}^{\text{List}^{A}}} & h\times t\rightarrow h\pplus\big(t\triangleright\overline{\text{ftn}}^{\text{List}^{A}}\big)
\end{array}\,\bef\,\begin{array}{||c|}
1\rightarrow1+\bbnum 0^{:A\times\text{List}^{A}}\\
h\times t\rightarrow h\pplus(t\triangleright\overline{\text{ftn}})
\end{array}\quad.
\]
We cannot split the column because the expression $h\pplus\big(t\triangleright\overline{\text{ftn}}^{\text{List}^{A}}\big)$
may evaluate to any part of the disjunction $\bbnum 1+\text{List}^{A}\times\text{List}^{\text{List}^{A}}$
depending on the values of $h$ and $t$. We are unable to compose
the result with the second matrix unless we identify that part of
the disjunction and then substitute into the first or the second column
of that matrix. A general recipe in such situations is to perform
additional pattern matching on the arguments of the function and to
substitute the results into the matrix. Consider the value of $h:\text{List}^{\text{List}^{A}}$,
which can be an empty list, $h=1+\bbnum 0$, or a product, $h=\bbnum 0+g^{:\text{List}^{A}}\times k^{:\text{List}^{\text{List}^{A}}}$.
Substitute these possibilities into the matrix expression for $\text{ftn}^{\text{List}^{A}}\bef\text{ftn}^{A}$:
\begin{align*}
{\color{greenunder}\text{with }h=1+\bbnum 0:}\quad & \left(\bbnum 0+\left(1+\bbnum 0\right)\times t\right)\triangleright\text{ftn}^{\text{List}^{A}}\bef\text{ftn}^{A}=\gunderline{\left(1+\bbnum 0\right)\pplus}\big(t\triangleright\overline{\text{ftn}^{\text{List}^{A}}}\bef\text{ftn}^{A}\big)\\
{\color{greenunder}\text{concatenate with empty list}:}\quad & =t\triangleright\overline{\text{ftn}^{\text{List}^{A}}}\triangleright\text{ftn}^{A}\quad.
\end{align*}
Substituting this value $h$ into $\text{ftn}^{\uparrow\text{List}}\bef\text{ftn}^{A}$,
we get 
\[
\left(\bbnum 0+\left(1+\bbnum 0\right)\times t\right)\triangleright\text{ftn}^{\uparrow\text{List}}\bef\text{ftn}^{A}=t\triangleright\overline{\text{ftn}^{\overline{\uparrow\text{List}}}}\triangleright\overline{\text{ftn}}\quad.
\]
Now we just need to show that
\[
t\triangleright\overline{\text{ftn}^{\text{List}^{A}}}\triangleright\text{ftn}^{A}\overset{?}{=}t\triangleright\overline{\text{ftn}^{\overline{\uparrow\text{List}}}}\triangleright\overline{\text{ftn}}\quad.
\]
This holds by the inductive assumption.

It remains to examine the second possibility, $h=\bbnum 0+g\times k$:
\begin{align*}
{\color{greenunder}\text{with }h=\bbnum 0+g\times k:}\quad & \left(\bbnum 0+\left(\bbnum 0+g\times k\right)\times t\right)\triangleright\text{ftn}^{\text{List}^{A}}\bef\text{ftn}^{A}=\big(\left(\bbnum 0+g\times k\right)\pplus\big(t\triangleright\overline{\text{ftn}^{\text{List}^{A}}}\big)\big)\triangleright\text{ftn}^{A}\\
{\color{greenunder}\text{code of }\pplus:}\quad & =\big(\bbnum 0+g\times\big(k\pplus\big(t\triangleright\overline{\text{ftn}^{\text{List}^{A}}}\big)\big)\big)\triangleright\text{ftn}^{A}\\
{\color{greenunder}\text{code of }\text{ftn}^{A}:}\quad & =g\pplus\big(k\pplus\big(t\triangleright\overline{\text{ftn}^{\text{List}^{A}}}\big)\big)\triangleright\overline{\text{ftn}}\\
{\color{greenunder}\text{Exercise~\ref{subsec:Exercise-flatten-concat-distributive-law}}:}\quad & =\gunderline{g\pplus\big(k\triangleright\overline{\text{ftn}}\big)}\pplus\big(t\triangleright\overline{\text{ftn}^{\text{List}^{A}}}\triangleright\overline{\text{ftn}}\big)=\left(\bbnum 0+g\times k\right)\triangleright\overline{\text{ftn}}\pplus\big(\gunderline{t\triangleright\overline{\text{ftn}^{\text{List}^{A}}}\triangleright\overline{\text{ftn}}}\big)\\
{\color{greenunder}\text{inductive assumption}:}\quad & =\text{ftn}\,(h)\pplus\big(t\triangleright\overline{\text{ftn}^{\uparrow\text{List}}}\triangleright\overline{\text{ftn}}\big)\quad.
\end{align*}
This is the same as the result of substituting $\bbnum 0+h\times t$
into $\text{ftn}^{\uparrow\text{List}}\bef\text{ftn}^{A}$.

\subsubsection{Example \label{subsec:Example-flatten-verify-for-monad-5}\ref{subsec:Example-flatten-verify-for-monad-5}}

Consider the \lstinline!List! type constructor with a \lstinline!flatten!
method that concatenates the nested lists in \emph{reverse} order.
Show that this implementation violates the associativity law of \lstinline!flatten!.

\subparagraph{Solution}

Apply both sides of the law to the nested list $p\triangleq\left[\left[\left[a,b\right],\left[c,d\right]\right],\left[\left[e,f\right],\left[g,h\right]\right]\right]$:
\begin{align*}
 & p\triangleright\text{ftn}^{\uparrow\text{List}}=\left[\left[c,d,a,b\right],\left[g,h,e,f\right]\right]\quad,\\
{\color{greenunder}\text{left-hand side}:}\quad & p\triangleright\text{ftn}^{\uparrow\text{List}}\triangleright\text{ftn}=\left[g,h,e,f,c,d,a,b\right]\quad,\\
 & p\triangleright\text{ftn}^{\text{List}^{A}}=\left[\left[e,f\right],\left[g,h\right],\left[a,b\right],\left[c,d\right]\right]\quad,\\
{\color{greenunder}\text{right-hand side}:}\quad & p\triangleright\text{ftn}^{\text{List}^{A}}\triangleright\text{ftn}=\left[c,d,a,b,g,h,e,f\right]\quad.
\end{align*}
The results are not the same. So, $p$ is a counterexample that refutes
the associativity law.

\subsubsection{Example \label{subsec:Example-flatten-verify-for-monad-2}\ref{subsec:Example-flatten-verify-for-monad-2}}

Show that the \lstinline!Writer! semimonad, $F^{A}\triangleq A\times W$,
is lawful if $W$ is a semigroup.

\subparagraph{Solution}

The type signature of \lstinline!flatten! is $\text{ftn}:\left(A\times W\right)\times W\rightarrow A\times W$,
and the code is
\[
\text{ftn}:\left(a\times w_{1}\right)\times w_{2}\rightarrow a\times\left(w_{1}\oplus w_{2}\right)\quad,
\]
where $\oplus$ is the binary operation of the semigroup $W$. The
lifting to $F$ is $f^{\uparrow F}=a\times w\rightarrow\left(a\triangleright f\right)\times w$,
so
\[
\text{ftn}^{\uparrow F}=\left(\left(a\times w_{1}\right)\times w_{2}\right)\times w_{3}\rightarrow\left(\left(\left(a\times w_{1}\right)\times w_{2}\right)\triangleright\text{ftn}\right)\times w_{3}=\left(a\times\left(w_{1}\oplus w_{2}\right)\right)\times w_{3}\quad.
\]
To verify the associativity law, it is convenient to substitute a
value $\left(\left(a\times w_{1}\right)\times w_{2}\right)\times w_{3}$
of type $F^{F^{F^{A}}}$ into both sides of the law:
\begin{align*}
 & \left(\left(\left(a\times w_{1}\right)\times w_{2}\right)\times w_{3}\right)\triangleright\text{ftn}^{\uparrow F}\triangleright\text{ftn}=\left(\left(a\times\left(w_{1}\oplus w_{2}\right)\right)\times w_{3}\right)\triangleright\text{ftn}=a\times\left(\left(w_{1}\oplus w_{2}\right)\oplus w_{3}\right)\quad,\\
 & \left(\left(\left(a\times w_{1}\right)\times w_{2}\right)\times w_{3}\right)\triangleright\text{ftn}^{F^{A}}\triangleright\text{ftn}=\left(\left(a\times w_{1}\right)\times\left(w_{2}\oplus w_{3}\right)\right)\triangleright\text{ftn}=a\times\left(w_{1}\oplus\left(w_{2}\oplus w_{3}\right)\right)\quad.
\end{align*}
The operation $\oplus$ is associative since $W$ is a semigroup.
So, both sides of the law are equal.

\subsubsection{Example \label{subsec:Example-flatten-verify-for-monad-4}\ref{subsec:Example-flatten-verify-for-monad-4}}

Consider the functor $F^{A}\triangleq A\times V\times V$ with the
\lstinline!flatten! method defined by
\[
\text{ftn}\triangleq\big(a^{:A}\times u_{1}^{:V}\times u_{2}^{:V}\big)\times v_{1}^{:V}\times v_{2}^{:V}\rightarrow a\times v_{2}\times v_{1}\quad.
\]
Show that this definition violates the associativity law of \lstinline!flatten!.

\subparagraph{Solution}

Substitute a value of type $F^{F^{F^{A}}}$ into both sides of the
law and get unequal results:
\begin{align*}
 & \left(\left(\left(a\times u_{1}\times u_{2}\right)\times v_{1}\times v_{2}\right)\times w_{1}\times w_{2}\right)\triangleright\text{ftn}^{\uparrow F}\triangleright\text{ftn}=\left(\left(a\times v_{2}\times v_{1}\right)\times w_{1}\times w_{2}\right)\triangleright\text{ftn}=a\times w_{2}\times w_{1}\quad,\\
 & \left(\left(\left(a\times u_{1}\times u_{2}\right)\times v_{1}\times v_{2}\right)\times w_{1}\times w_{2}\right)\triangleright\text{ftn}^{F^{A}}\triangleright\text{ftn}=\left(\left(a\times u_{1}\times u_{2}\right)\times w_{2}\times w_{1}\right)\triangleright\text{ftn}=a\times w_{1}\times w_{2}\quad.
\end{align*}
Had the code not exchanged the order of $w_{1}$ and $w_{2}$, the
law would have held.

\subsection{From semimonads to monads: Motivation for the identity laws}

Semimonads are heuristically viewed as values with a special \textsf{``}computational
effect\textsf{''}. Semimonad-valued computations can be composed using the
\lstinline!flatMap! method, which will \textsf{``}merge\textsf{''} the effects associatively.
It is generally useful to be able to create values with an \textsf{``}empty
effect\textsf{''}, such that merging the empty effect leaves other effects
unchanged. A full monad $M$ is a semimonad that has a method for
creating values with \textsf{``}empty effect\textsf{''}. That method is called \lstinline!pure!
(notation $\text{pu}_{M}$):

\begin{wrapfigure}{l}{0.475\columnwidth}%
\vspace{-0.8\baselineskip}
\begin{lstlisting}
def pure[A](a: A): M[A]
\end{lstlisting}
\vspace{-0.6\baselineskip}
\end{wrapfigure}%

~\vspace{-0.5\baselineskip}
\[
\text{pu}_{M}^{A}:A\rightarrow M^{A}\quad.
\]

To get intuition about the properties of a vaguely defined \textsf{``}empty
effect\textsf{''}, again consider nested iteration over arrays. The \textsf{``}empty
effect\textsf{''} is an array containing \emph{one} element, because an iteration
of such an array goes over a single value, which is equivalent to
no iteration. In a functor block, this intuition says that a source
line with an \textsf{``}empty effect\textsf{''}, \lstinline!y <- pure(x)!, should
be equivalent to just \lstinline!y = x!. This line must occur either
before or after another source line, for instance:

\begin{comment}
So, we need to examine two possibilities: first, an empty effect comes
before another source line,
\end{comment}

\noindent \texttt{\textcolor{blue}{\footnotesize{}}}%
\begin{minipage}[c]{0.475\columnwidth}%
\texttt{\textcolor{blue}{\footnotesize{}}}
\begin{lstlisting}
result1 = for {
    ... // Some code, then:
    y <- pure(x)   // "Empty effect" with x: A.
    z <- someArray(y)   // someArray: A => M[B]
     // Same as z <- pure(x).flatMap(someArray)
\end{lstlisting}
%
\end{minipage}\texttt{\textcolor{blue}{\footnotesize{}\hspace*{\fill}}}%
\begin{minipage}[c]{0.475\columnwidth}%
\texttt{\textcolor{blue}{\footnotesize{}}}
\begin{lstlisting}
result2 = for {
    ... // Some code, then:
    y = x               // x: A
    z <- someArray(y)   // someArray: A => M[B]
    // Same as z <- someArray(x)
\end{lstlisting}
%
\end{minipage}{\footnotesize\par}

\noindent \vspace{0.1\baselineskip}
The equality of \lstinline!result1! and \lstinline!result2! gives
the following law: for all $g^{:A\rightarrow M^{B}}$,

\begin{wrapfigure}{l}{0.3\columnwidth}%
\vspace{-0.9\baselineskip}
\begin{lstlisting}
pure(x).flatMap(g) == g(x)
\end{lstlisting}
\vspace{-0.6\baselineskip}
\end{wrapfigure}%

~\vspace{-1.4\baselineskip}
\begin{align}
{\color{greenunder}\text{left identity law of }M:}\quad & \text{pu}_{M}\bef\text{flm}_{M}(g^{:A\rightarrow M^{B}})=g\quad.\label{eq:monad-left-identity-law-for-flatMap}
\end{align}
\vspace{-1.2\baselineskip}

The second possibility is that an empty effect comes \emph{after}
a source line:

\noindent \texttt{\textcolor{blue}{\footnotesize{}}}%
\begin{minipage}[c]{0.475\columnwidth}%
\texttt{\textcolor{blue}{\footnotesize{}}}
\begin{lstlisting}
result1 = for {
    x <- someArray   // someArray: M[A]
    y <- pure(x)     // Empty effect with x: A.
// Same as y <- someArray.flatMap(x => pure(x))
\end{lstlisting}
%
\end{minipage}\texttt{\textcolor{blue}{\footnotesize{}\hspace*{\fill}}}%
\begin{minipage}[c]{0.475\columnwidth}%
\texttt{\textcolor{blue}{\footnotesize{}}}
\begin{lstlisting}
result2 = for {
    x <- someArray   // someArray: M[A]
    y = x
    // Same as y <- someArray
\end{lstlisting}
%
\end{minipage}{\footnotesize\par}

\noindent \vspace{0.1\baselineskip}
Then the equality of \lstinline!result1! and \lstinline!result2!
gives the law

\begin{wrapfigure}{l}{0.3\columnwidth}%
\vspace{-0.85\baselineskip}
\begin{lstlisting}
g.flatMap(pure) == g
\end{lstlisting}
\vspace{-0.6\baselineskip}
\end{wrapfigure}%

~\vspace{-1.4\baselineskip}
\begin{align}
{\color{greenunder}\text{right identity law of }M:}\quad & \text{flm}_{M}(\text{pu}_{M})=\text{id}^{:M^{A}\rightarrow M^{A}}\quad.\label{eq:monad-right-identity-law-for-flatMap}
\end{align}

A typeclass\index{typeclass!Monad@\texttt{Monad}} for monads and
a law-checking test function can be defined by
\begin{lstlisting}
abstract class Monad[F[_]: Functor : Semimonad] {
  def pure[A](a: A): F[A]
}
def checkMonadIdentityLaws[F[_], A, B]()(implicit mf: Monad[F], sf: Semimonad[F],
      aa: Arbitrary[A], af: Arbitrary[F[A]], ab: Arbitrary[A => F[B]]) = {
    forAll { (x: A, g: A => F[B]) =>               
      mf.pure(x).flatMap(g) shouldEqual g(x)   // Left identity law.
    }
    forAll { (fa: F[A]) =>               
      fa.flatMap(mf.pure[A]) shouldEqual fa   // Right identity law.
    }
}
\end{lstlisting}

Note that \lstinline!pure! is the same method as in the \lstinline!Pointed!
typeclass (Sections~\ref{subsec:Pointed-functors:-motivation}\textendash \ref{subsec:Pointed-functors:-structural-analysis}).
So, we could say that a monad is a pointed semimonad whose \lstinline!pure!
method obeys the two identity laws~(\ref{eq:monad-left-identity-law-for-flatMap})\textendash (\ref{eq:monad-right-identity-law-for-flatMap}).
Although the \lstinline!pure! method can be replaced by a simpler
\textsf{``}wrapped unit\textsf{''} value ($\text{wu}_{M}$), having no laws, derivations
turn out to be easier when using $\text{pu}_{M}$.

The \lstinline!Pointed! typeclass requires the \lstinline!pure!
method to satisfy the naturality law~(\ref{eq:naturality-law-of-pure}).
A full monad\textsf{'}s \lstinline!pure! method must satisfy that law, in
addition to the identity laws.

Just as some useful semigroups are not monoids, there exist some useful
semimonads that are not full monads. A simple example is the \lstinline!Writer!
semimonad $F^{A}\triangleq A\times W$ whose type $W$ is a semigroup
but not a monoid (see Exercise~\ref{subsec:Exercise-semimonad-not-monad}).

\subsection{The monad identity laws in terms of \texttt{pure} and \texttt{flatten}}

Since the laws of semimonads are simpler when formulated via the \lstinline!flatten!
method, let us convert the identity laws to that form. We use the
code for \lstinline!flatMap! in terms of \lstinline!flatten!,
\[
\text{flm}_{M}(f^{:A\rightarrow M^{B}})=f^{\uparrow M}\bef\text{ftn}_{M}\quad.
\]
Begin with the left identity law of \lstinline!flatMap!, written
as

\begin{wrapfigure}{l}{0.32\columnwidth}%
\vspace{-1\baselineskip}

\[
\xymatrix{\xyScaleY{0.5pc}\xyScaleX{3pc} & M^{M^{A}}\ar[rd]\sp(0.5){\ \text{ftn}^{A}\ }\\
M^{A}\ar[ru]\sp(0.5){\text{pu}^{M^{A}}\ }\ar[rr]\sb(0.5){\text{id}} &  & M^{A}
}
\]
\vspace{-0.2\baselineskip}
\end{wrapfigure}%

~\vspace{-0.8\baselineskip}
\[
\text{pu}_{M}\bef\text{flm}_{M}(f)=f\quad.
\]

Since this law holds for arbitrary $f$, we can set $f\triangleq\text{id}$
and get
\begin{equation}
\text{pu}_{M}\bef\text{ftn}_{M}=\text{id}^{:M^{A}\rightarrow M^{A}}\quad.\label{eq:left-identity-law-for-flatten}
\end{equation}
\vspace{-0.5\baselineskip}

\noindent This is the \textbf{left identity law} of \lstinline!flatten!.
Conversely, if Eq.~(\ref{eq:left-identity-law-for-flatten}) holds,
we can compose both sides with an arbitrary function $f^{:A\rightarrow M^{B}}$
and recover the left identity law of \lstinline!flatMap! (Exercise~\ref{subsec:Exercise-1-monads-2}).

The \index{identity laws!of pure and flatten@of \texttt{pure} and \texttt{flatten}}\textbf{right
identity law} of \lstinline!flatten! is written as

\begin{wrapfigure}{l}{0.32\columnwidth}%
\vspace{-2\baselineskip}

\[
\xymatrix{\xyScaleY{0.2pc}\xyScaleX{3pc} & M^{M^{A}}\ar[rd]\sp(0.5){\ \text{ftn}^{A}\ }\\
M^{A}\ar[ru]\sp(0.5){(\text{pu}^{A})^{\uparrow M}\quad}\ar[rr]\sb(0.5){\text{id}} &  & M^{A}
}
\]
\vspace{-1\baselineskip}
\end{wrapfigure}%

~\vspace{-0.6\baselineskip}
\begin{align}
 & \text{flm}_{M}(\text{pu}_{M})=\text{pu}_{M}^{\uparrow M}\bef\text{ftn}_{M}\overset{!}{=}\text{id}\quad.\label{eq:right-identity-law-for-flatten}
\end{align}
\vspace{-0.1\baselineskip}

In the next section, we will see a reason why these laws have their
names.

\subsection{Monad laws in terms of Kleisli functions}

A \textbf{Kleisli function}\index{Kleisli!functions|textit} is a
function with type signature $A\rightarrow M^{B}$ where $M$ is a
monad. We first encountered Kleisli functions in Section~\ref{subsec:Motivation-and-laws-for-liftopt}
when deriving the laws of filterable functors using the \lstinline!liftOpt!
method. At that point, $M$ was the simple \lstinline!Option! monad.
We found that functions of type $A\rightarrow\bbnum 1+B$ can be composed
using the Kleisli composition denoted by $\diamond_{_{\text{Opt}}}$
(see page~\pageref{kleisli-composition}). Later, Section~\ref{subsec:Generalizing-the-laws-of-liftings-kleisli-functions}
stated the general properties of Kleisli composition. We will now
show that the Kleisli composition gives a useful way of formulating
the laws of a monad.

The Kleisli composition\index{Kleisli composition} operation for
a monad $M$, denoted $\diamond_{_{M}}$, is a function with type
signature
\[
\diamond_{_{M}}:(A\rightarrow M^{B})\rightarrow(B\rightarrow M^{C})\rightarrow A\rightarrow M^{C}\quad.
\]
This resembles the forward composition of ordinary functions, $\left(\bef\right):\left(A\rightarrow B\right)\rightarrow\left(B\rightarrow C\right)\rightarrow A\rightarrow C$,
except for different types of functions. If $M$ is a monad, the implementation
of $\diamond_{_{M}}$ is

\begin{wrapfigure}{l}{0.67\columnwidth}%
\vspace{-0.8\baselineskip}
\begin{lstlisting}
def <>[M[_]: Monad, A,B,C](f: A => M[B], g: B => M[C]): A => M[C] =
  { x => f(x).flatMap(g) }
\end{lstlisting}
\vspace{-0.9\baselineskip}
\end{wrapfigure}%

~\vspace{-0.8\baselineskip}
\begin{equation}
f\diamond_{_{M}}g\triangleq f\bef\text{flm}_{M}(g)\quad.\label{eq:def-of-kleisli-composition-for-monad-via-flatMap}
\end{equation}
\vspace{-0.5\baselineskip}

The Kleisli composition can be equivalently expressed by a functor
block code as

\begin{lstlisting}[mathescape=true]
def <>[M[_]: Monad, A,B,C](f: A => M[B], g: B => M[C]): A => M[C] = { x =>
  for {
    y <- f(x)
    z <- g(y)
  } yield z
}
\end{lstlisting}

This example shows that Kleisli composition is a basic part of functor
block code: it expresses the chaining of two consecutive \textsf{``}source\textsf{''}
lines.

Let us now derive the laws of Kleisli composition $\diamond_{_{M}}$,
assuming that the monad laws hold for $M$. 

\subsubsection{Statement \label{subsec:Statement-identity-laws-for-kleisli}\ref{subsec:Statement-identity-laws-for-kleisli}}

For a lawful monad $M$, the Kleisli composition $\diamond_{_{M}}$
satisfies the identity laws
\begin{align}
{\color{greenunder}\text{left identity law of }\diamond_{_{M}}:}\quad & \text{pu}_{M}\diamond_{_{M}}f=f\quad,\quad\forall f^{:A\rightarrow M^{B}}\quad,\label{eq:kleisli-left-identity-law}\\
{\color{greenunder}\text{right identity law of }\diamond_{_{M}}:}\quad & f\diamond_{_{M}}\text{pu}_{M}=f\quad,\quad\forall f^{:A\rightarrow M^{B}}\quad.\label{eq:kleisli-right-identity-law}
\end{align}


\subparagraph{Proof}

We may assume that Eqs.~(\ref{eq:monad-left-identity-law-for-flatMap})\textendash (\ref{eq:monad-right-identity-law-for-flatMap})
hold. Using the definition~(\ref{eq:def-of-kleisli-composition-for-monad-via-flatMap}),
we find
\begin{align*}
{\color{greenunder}\text{left identity law of }\diamond_{_{M}},\text{ should equal }f:}\quad & \text{pu}_{M}\diamond_{_{M}}f=\gunderline{\text{pu}_{M}\bef\text{flm}_{M}}(f)\\
{\color{greenunder}\text{use Eq.~(\ref{eq:monad-left-identity-law-for-flatMap})}:}\quad & =f\quad,\\
{\color{greenunder}\text{right identity law of }\diamond_{_{M}},\text{ should equal }f:}\quad & f\diamond_{_{M}}\text{pu}_{M}=f\bef\gunderline{\text{flm}_{M}(\text{pu}_{M})}\\
{\color{greenunder}\text{use Eq.~(\ref{eq:monad-right-identity-law-for-flatMap})}:}\quad & \quad=f\bef\text{id}=f\quad.
\end{align*}

The following statement and the identity law~(\ref{eq:monad-right-identity-law-for-flatMap})
show that \lstinline!flatMap! can be viewed as a \textsf{``}lifting\textsf{''},
\[
\text{flm}_{M}:(A\rightarrow M^{B})\rightarrow(M^{A}\rightarrow M^{B})\quad,
\]
from Kleisli functions $A\rightarrow M^{B}$ to $M$-lifted functions
$M^{A}\rightarrow M^{B}$, except that Kleisli functions must be composed
using $\diamond_{_{M}}$, while $\text{pu}_{M}$ plays the role of
the Kleisli-identity function.

\subsubsection{Statement \label{subsec:Statement-flatMap-lifting-composition-law-for-kleisli}\ref{subsec:Statement-flatMap-lifting-composition-law-for-kleisli}}

For a lawful monad $M$, the \lstinline!flatMap! method satisfies
the composition law\index{composition law!of flatMap@of \texttt{flatMap}}

\begin{wrapfigure}{l}{0.32\columnwidth}%
\vspace{-1.5\baselineskip}

\[
\xymatrix{\xyScaleY{0.8pc}\xyScaleX{3pc} & M^{B}\ar[rd]\sp(0.5){\ \text{flm}_{M}(g)\ }\\
M^{A}\ar[ru]\sp(0.5){\text{flm}_{M}(f)\quad}\ar[rr]\sb(0.5){\text{flm}_{M}(f\diamond_{_{_{M}}}g)} &  & M^{C}
}
\]
\vspace{0.1\baselineskip}
\end{wrapfigure}%

~\vspace{-0.2\baselineskip}
\[
\text{flm}_{M}(f\diamond_{_{_{M}}}g)=\text{flm}_{M}(f)\bef\text{flm}_{M}(g)\quad.
\]
\vspace{-0.8\baselineskip}


\subparagraph{Proof}

We may use Eq.~(\ref{eq:associativity-law-flatMap}) since $M$ is
a lawful monad. A direct calculation yields the law:
\begin{align*}
{\color{greenunder}\text{expect to equal }\text{flm}_{M}(f)\bef\text{flm}_{M}(g):}\quad & \text{flm}_{M}(f\diamond_{_{_{M}}}g)=\text{flm}_{M}(f\bef\text{flm}_{M}(g))\\
{\color{greenunder}\text{use Eq.~(\ref{eq:associativity-law-flatMap})}:}\quad & =\text{flm}_{M}(f)\bef\text{flm}_{M}(g)\quad.
\end{align*}

The following statement motivates calling Eq.~(\ref{eq:associativity-law-flatMap})
an \textsf{``}associativity\textsf{''} law.

\subsubsection{Statement \label{subsec:Statement-associativity-law-for-kleisli}\ref{subsec:Statement-associativity-law-for-kleisli}}

For a lawful monad $M$, the Kleisli composition $\diamond_{_{M}}$
satisfies the \textbf{associativity law}\index{associativity law!of Kleisli composition}
\begin{align}
 & \left(f\diamond_{_{M}}g\right)\diamond_{_{M}}h=f\diamond_{_{M}}\left(g\diamond_{_{M}}h\right)\quad,\quad\quad\forall f^{:A\rightarrow M^{B}},\,g^{:B\rightarrow M^{C}},\,h^{:C\rightarrow M^{D}}\quad.\label{eq:kleisli-associativity-law}
\end{align}
So, we may write $f\diamond_{_{M}}g\diamond_{_{M}}h$ unambiguously
with no parentheses.

\subparagraph{Proof}

Substitute Eq.~(\ref{eq:def-of-kleisli-composition-for-monad-via-flatMap})
into both sides of the law:
\begin{align*}
{\color{greenunder}\text{left-hand side}:}\quad & (\gunderline{f\diamond_{_{M}}g})\diamond_{_{M}}h=\left(f\bef\text{flm}_{M}(g)\right)\gunderline{\diamond_{_{M}}h}=f\bef\text{flm}_{M}(g)\bef\text{flm}_{M}(h)\quad,\\
{\color{greenunder}\text{right-hand side}:}\quad & \gunderline{f\diamond_{_{M}}}(g\diamond_{_{M}}h)=f\bef\gunderline{\text{flm}_{M}(g\diamond_{_{M}}h)}\\
{\color{greenunder}\text{use Statement~\ref{subsec:Statement-flatMap-lifting-composition-law-for-kleisli}}:}\quad & \quad=f\bef\text{flm}_{M}(g)\bef\text{flm}_{M}(h)\quad.
\end{align*}
Both sides of the law are now equal.

We find that the properties of the operation $\diamond_{_{M}}$ are
similar to the identity and associativity properties of the function
composition $f\bef g$ except for using $\text{pu}_{M}$ instead of
the identity function.\footnote{It means that Kleisli functions satisfy the properties of morphisms
of a category; see Section~\ref{subsec:Motivation-for-using-category-theory}.}

Since the Kleisli composition describes the chaining of consecutive
lines in functor blocks, its associativity means that multiple lines
are chained unambiguously. For example, this code:

\begin{wrapfigure}{l}{0.14\columnwidth}%
\vspace{0.1\baselineskip}

\begin{lstlisting}[numbers=left]
x => for {
  y <- f(x)
  z <- g(y)
  t <- h(z)
} yield t
\end{lstlisting}
\vspace{0\baselineskip}
\end{wrapfigure}%

\noindent corresponds to the Kleisli composition\vspace{-0.2\baselineskip}
\[
(x\rightarrow f(x))\diamond_{_{_{M}}}(y\rightarrow g(y))\diamond_{_{_{M}}}(z\rightarrow h(z))
\]
and does not need to specify whether lines 2 and 3 are chained before
appending line 4, or lines 3 and 4 are chained before prepending line
2.

We will now prove that the Kleisli composition with its laws is equivalent
to \lstinline!flatMap! with \emph{its} laws. In other words, we may
equally well use the Kleisli composition when formulating the requirements
for a functor $M$ to be a monad.

\subsubsection{Statement \label{subsec:Statement-equivalence-kleisli-composition-and-flatMap}\ref{subsec:Statement-equivalence-kleisli-composition-and-flatMap}}

The types of Kleisli composition $\diamond_{_{M}}$ and of $M$\textsf{'}s
\lstinline!flatMap! are equivalent,
\begin{equation}
f^{:A\rightarrow M^{B}}\diamond_{_{M}}g^{:B\rightarrow M^{C}}=f\bef\text{flm}_{M}(g)\quad,\quad\quad\text{flm}_{M}(f^{:A\rightarrow M^{B}})=\text{id}^{:M^{A}\rightarrow M^{A}}\diamond_{_{M}}f\quad,\label{eq:express-kleisli-composition-via-flatMap-and-back}
\end{equation}
provided that Eqs.~(\ref{eq:kleisli-left-identity-law})\textendash (\ref{eq:kleisli-associativity-law})
and the following additional law hold for $\diamond_{_{M}}$:
\begin{align}
{\color{greenunder}\text{left naturality of }\diamond_{_{M}}:}\quad & (f^{:A\rightarrow B}\bef g^{:B\rightarrow M^{C}}\big)\diamond_{_{M}}h^{:C\rightarrow M^{D}}=f\bef\big(g\diamond_{_{M}}h\big)\quad.\label{eq:left-naturality-of-kleisli-composition}
\end{align}
Note that this law makes parentheses unnecessary in the expression
$f\bef g\diamond_{_{M}}h$.\index{Kleisli composition!with function composition}

\subparagraph{Proof}

Equations~(\ref{eq:express-kleisli-composition-via-flatMap-and-back})
map $\diamond_{_{M}}$ to $\text{flm}_{M}$ and back. We have to show
that these mappings are isomorphisms when the given laws hold. We
proceed in two steps:

(1) Given an operation $\diamond_{_{M}}$, we define $\text{flm}_{M}$
and then a new operation $\diamond_{_{M}}^{\prime}$ using Eq.~(\ref{eq:express-kleisli-composition-via-flatMap-and-back}).
We then need to prove that $\diamond_{_{M}}^{\prime}=\diamond_{_{M}}$.
Calculate using arbitrary functions $f^{:A\rightarrow M^{B}}$ and
$g^{:B\rightarrow M^{C}}$:
\begin{align*}
{\color{greenunder}\text{use Eq.~(\ref{eq:express-kleisli-composition-via-flatMap-and-back})}:}\quad & f\diamond_{_{M}}^{\prime}g=f\bef\text{flm}_{M}(g)=f\bef\big(\text{id}^{M^{B}}\diamond_{_{M}}g\big)\\
{\color{greenunder}\text{left naturality~(\ref{eq:left-naturality-of-kleisli-composition}) of }\diamond_{_{M}}:}\quad & =(\gunderline{f\bef\text{id}})\diamond_{_{M}}g=f\diamond_{_{M}}g\quad.
\end{align*}

When $\diamond_{_{M}}$ is defined via $\text{flm}_{M}$, the left
naturality law~(\ref{eq:left-naturality-of-kleisli-composition})
will hold because \textsf{``}$\bef$\textsf{''} is associative,
\begin{align*}
 & (f\bef g)\diamond_{_{M}}h=(f\bef g)\bef\text{flm}_{M}(h)=f\bef(g\bef\text{flm}_{M}(h))=f\bef(g\diamond_{_{M}}h)\quad.
\end{align*}

(2) Given a function $\text{flm}_{M}$, we define $\diamond_{_{M}}$
and then a new function $\text{flm}_{M}^{\prime}$ using Eq.~(\ref{eq:express-kleisli-composition-via-flatMap-and-back}).
We then need to prove that $\text{flm}_{M}^{\prime}=\text{flm}_{M}$.
Calculate using an arbitrary function $f^{:A\rightarrow M^{B}}$:
\begin{align*}
{\color{greenunder}\text{use Eq.~(\ref{eq:express-kleisli-composition-via-flatMap-and-back})}:}\quad & \text{flm}_{M}^{\prime}(f)=\text{id}^{M^{A}}\diamond_{_{M}}f=\gunderline{\text{id}}\bef\text{flm}_{M}(f)=\text{flm}_{M}(f)\quad.
\end{align*}

We have already derived the laws of Kleisli composition from the laws
of \lstinline!flatMap!. We will now derive the converse statement.
In this way, we will show that the Kleisli composition laws and the
\lstinline!flatMap! laws are fully equivalent.

\subsubsection{Statement \label{subsec:Statement-equivalence-kleisli-laws-and-flatMap-laws}\ref{subsec:Statement-equivalence-kleisli-laws-and-flatMap-laws}}

If the Kleisli composition $\diamond_{_{M}}$ obeys the laws~(\ref{eq:kleisli-left-identity-law})\textendash (\ref{eq:kleisli-associativity-law}),
the corresponding \lstinline!flatMap! method defined by Eq.~(\ref{eq:express-kleisli-composition-via-flatMap-and-back})
will satisfy the laws~(\ref{eq:left-naturality-law-flatMap})\textendash (\ref{eq:associativity-law-flatMap}).

\subparagraph{Proof}

To derive the identity laws of \lstinline!flatMap!:
\begin{align*}
{\color{greenunder}\text{left identity law}:}\quad & \text{pu}_{M}\bef\gunderline{\text{flm}_{M}(f)}=\gunderline{\text{pu}_{M}\bef\text{id}}\diamond_{_{M}}f=\gunderline{\text{pu}_{M}\diamond_{_{M}}}f=f\quad,\\
{\color{greenunder}\text{right identity law}:}\quad & \text{flm}_{M}(\text{pu}_{M})=\text{id}\,\gunderline{\diamond_{_{M}}\text{pu}_{M}}=\text{id}\quad.
\end{align*}

To derive the associativity law~(\ref{eq:associativity-law-flatMap})
of \lstinline!flatMap!, substitute the definition of $\text{flm}_{M}$
into both sides:
\begin{align*}
{\color{greenunder}\text{left-hand side}:}\quad & \text{flm}_{M}(f\bef\text{flm}_{M}(g))=\text{id}\diamond_{_{M}}(\gunderline{f\bef\text{id}}\diamond_{_{M}}g)=\text{id}\diamond_{_{M}}(f\diamond_{_{M}}g)\\
{\color{greenunder}\text{associativity law~(\ref{eq:kleisli-associativity-law})}:}\quad & \quad=(\text{id}\diamond_{_{M}}f)\diamond_{_{M}}g\quad,\\
{\color{greenunder}\text{right-hand side}:}\quad & \text{flm}_{M}(f)\bef\text{flm}_{M}(g)=(\text{id}\diamond_{_{M}}f)\,\gunderline{\bef(\text{id}}\diamond_{_{M}}g)\\
{\color{greenunder}\text{left naturality~(\ref{eq:left-naturality-of-kleisli-composition}) of }\diamond_{_{M}}:}\quad & \quad=(\text{id}\diamond_{_{M}}f)\,\gunderline{\bef\text{id}}\diamond_{_{M}}g=(\text{id}\diamond_{_{M}}f)\diamond_{_{M}}g\quad.
\end{align*}
Both sides of the law are now equal.

The two naturality laws of \lstinline!flatMap! are equivalent to
the three naturality laws of $\diamond_{_{M}}$, but we omit those
derivations. 

\subsection{Verifying the monad laws using Kleisli functions}

When the monad laws are formulated via Kleisli composition, the intuition
behind the laws becomes clearer: they are analogous to the identity
and associativity laws of the function composition ($\bef$). The
price is that the type signatures become complicated. For instance,
the associativity law~(\ref{eq:kleisli-associativity-law}) has four
type parameters, while the corresponding law~(\ref{eq:associativity-law-of-flatten})
for \lstinline!flatten! has only one. For certain monads, however,
a trick called \index{flipped@\textsf{``}flipped Kleisli\textsf{''} technique|textit}\textbf{flipped
Kleisli} makes direct proofs of laws much shorter. That trick applies
to monads of a function type, such as the continuation and the state
monads.

\subsubsection{Statement \label{subsec:Statement-continuation-monad-is-lawful}\ref{subsec:Statement-continuation-monad-is-lawful}}

The continuation monad, $\text{Cont}^{R,A}\triangleq\left(A\rightarrow R\right)\rightarrow R$,
satisfies all monad laws.

\subparagraph{Proof}

Begin by writing the type of a Kleisli function corresponding to this
monad,
\[
A\rightarrow\text{Cont}^{R,B}=A\rightarrow\left(B\rightarrow R\right)\rightarrow R\quad.
\]
This function type has two curried arguments. The first step of the
flipped Kleisli technique is to change the types of the Kleisli functions
by flipping their two curried arguments. We obtain
\[
\left(B\rightarrow R\right)\rightarrow A\rightarrow R\quad.
\]
This type looks like a function of the form $K^{B}\rightarrow K^{A}$,
where we temporarily defined $K^{A}\triangleq A\rightarrow R$. The
remaining steps are to flip the arguments of $\text{pu}_{\text{Cont}}$
and get a modified $\tilde{\text{pu}}_{\text{Cont}}$. Then, we modify
the Kleisli composition $\diamond_{_{\text{Cont}}}$ into $\tilde{\diamond}_{_{\text{Cont}}}$.
The flipped Kleisli functions are composed using $\tilde{\diamond}_{_{\text{Cont}}}$.
We will then prove the laws
\[
\tilde{\text{pu}}_{\text{Cont}}\tilde{\diamond}_{_{\text{Cont}}}f=f\quad,\quad\quad f\,\tilde{\diamond}_{_{\text{Cont}}}\tilde{\text{pu}}_{\text{Cont}}=f\quad,\quad\quad(f\,\tilde{\diamond}_{_{\text{Cont}}}g)\,\tilde{\diamond}_{_{\text{Cont}}}h=f\,\tilde{\diamond}_{_{\text{Cont}}}(g\,\tilde{\diamond}_{_{\text{Cont}}}h)\quad.
\]
Flipping the arguments is an operation that maps functions to equivalent
functions. So, if we prove the laws of identity and composition for
flipped Kleisli functions, it will follow that the same laws hold
for the original functions.

The original \lstinline!pure! method is 
\[
\text{pu}_{\text{Cont}}\triangleq a^{:A}\rightarrow f^{:A\rightarrow R}\rightarrow f(a)\quad.
\]
We find that the flipped \lstinline!pure! method is just an identity
function:
\[
\tilde{\text{pu}}_{\text{Cont}}\triangleq f^{:A\rightarrow R}\rightarrow a^{:A}\rightarrow f(a)=f^{:A\rightarrow R}\rightarrow f=\text{id}^{:\left(A\rightarrow R\right)\rightarrow A\rightarrow R}=\text{id}^{:K^{A}\rightarrow K^{A}}\quad.
\]
This is a significant simplification. The flipped Kleisli composition
$\tilde{\diamond}_{_{\text{Cont}}}$ has the type signature
\[
f^{:K^{B}\rightarrow K^{A}}\tilde{\diamond}_{_{\text{Cont}}}g^{:K^{C}\rightarrow K^{B}}=\text{???}^{:K^{C}\rightarrow K^{A}}\quad.
\]
There is only one implementation of that type signature, namely the
backward composition,
\[
f^{:K^{B}\rightarrow K^{A}}\tilde{\diamond}_{_{\text{Cont}}}g^{:K^{C}\rightarrow K^{B}}\triangleq g\bef f=f\circ g\quad.
\]
So, this must be the code of the flipped Kleisli composition. It is
now quick to verify the laws:
\begin{align*}
{\color{greenunder}\text{left identity law}:}\quad & \tilde{\text{pu}}_{\text{Cont}}\tilde{\diamond}_{_{\text{Cont}}}f=\text{id}\circ f=f\quad,\\
{\color{greenunder}\text{right identity law}:}\quad & f\,\tilde{\diamond}_{_{\text{Cont}}}\tilde{\text{pu}}_{\text{Cont}}=f\circ\text{id}=f\quad,\\
{\color{greenunder}\text{associativity law}:}\quad & \big(f\,\tilde{\diamond}_{_{\text{Cont}}}g\big)\,\tilde{\diamond}_{_{\text{Cont}}}h=(f\circ g)\circ h=f\circ(g\circ h)=f\,\tilde{\diamond}_{_{\text{Cont}}}\big(g\,\tilde{\diamond}_{_{\text{Cont}}}h\big)\quad.
\end{align*}
We could have avoided writing the last three lines by noticing that
functions of types $K^{B}\rightarrow K^{A}$ automatically satisfy
the laws of (backward) function composition (Section~\ref{subsec:Laws-of-function-composition}).

\subsubsection{Statement \label{subsec:Statement-state-monad-is-lawful}\ref{subsec:Statement-state-monad-is-lawful}}

The state monad, $\text{State}^{S,A}\triangleq S\rightarrow A\times S$,
satisfies all monad laws.

\subparagraph{Proof}

Begin by writing the type of a Kleisli function corresponding to this
monad,
\[
A\rightarrow\text{State}^{S,B}=A\rightarrow S\rightarrow B\times S\quad.
\]
An equivalent type is obtained by uncurrying the two arguments:
\[
\left(A\rightarrow S\rightarrow B\times S\right)\cong\left(A\times S\rightarrow B\times S\right)=K^{A}\rightarrow K^{B}\quad,
\]
where we temporarily defined $K^{A}\triangleq A\times S$. This type
looks like an ordinary function, which promises to simplify the proof.
Uncurrying is an equivalence transformation. So, let us uncurry the
arguments in all Kleisli functions and prove the laws in the \textsf{``}uncurried
Kleisli\textsf{''} formulation. We need to uncurry the arguments in $\text{pu}_{\text{State}}$
and $\diamond_{_{\text{State}}}$ as well. Denote the resulting functions
$\tilde{\text{pu}}_{\text{State}}$ and $\tilde{\diamond}_{_{\text{State}}}$:
\[
\tilde{\text{pu}}_{\text{State}}\triangleq a^{:A}\times s^{:S}\rightarrow a\times s=\text{id}^{:K^{A}\rightarrow K^{A}}\quad,\quad\quad f^{:K^{A}\rightarrow K^{B}}\tilde{\diamond}_{_{\text{State}}}g^{:K^{B}\rightarrow K^{C}}\triangleq f\bef g\quad.
\]
We can see that the composition $f\bef g$ implements the correct
logic of the state monad: an initial state value $s^{:S}$ is updated
by $f$ and then passed to $g$.

We found that the uncurried Kleisli functions have simple types $K^{A}\rightarrow K^{B}$,
and the operation $\tilde{\diamond}_{_{\text{State}}}$ is just the
ordinary composition of those functions. Since we already know that
the laws of identity and associativity hold for ordinary functions
(Section~\ref{subsec:Laws-of-function-composition}), the proof is
finished.

For comparison, look at the type signatures of \lstinline!flatten!
for the state and continuation monads:
\begin{align*}
\text{ftn}_{\text{State}^{S,\bullet}} & :\left(S\rightarrow\left(S\rightarrow A\times S\right)\times S\right)\rightarrow S\rightarrow A\times S\quad,\\
\text{ftn}_{\text{Cont}^{R,\bullet}} & :\left(\left(\left(\left(A\rightarrow R\right)\rightarrow R\right)\rightarrow R\right)\rightarrow R\right)\rightarrow\left(A\rightarrow R\right)\rightarrow R\quad.
\end{align*}
These type signatures are complicated and confusing to read. Direct
proofs of the monad laws for these functions are much longer than
the proofs of Statements~\ref{subsec:Statement-state-monad-is-lawful}\textendash \ref{subsec:Statement-continuation-monad-is-lawful}.
When a monad $M$ has a function type, the Kleisli function $A\rightarrow M^{B}$
has two curried arguments. Flipping or uncurrying these arguments
often produces an equivalent function that is easier to work with. 

\subsection{Structural analysis of semimonads and monads\label{subsec:Structural-analysis-of-monads}}

We have seen different examples of well-known monads that were discovered
by programmers working on specific tasks. Hoping to find systematically
all possible monads, we will now apply structural analysis to semimonads
and monads. For each type construction, we will prove rigorously that
the monad laws hold.

\paragraph{Type parameters}

Three type constructions are based on using just type parameters:
a constant functor, $\text{Const}^{Z,A}\triangleq Z$, the identity
functor $\text{Id}^{A}\triangleq A$, and the functor composition,
$L^{A}\triangleq F^{G^{A}}$.

A constant functor $F^{A}\triangleq Z$ is a lawful semimonad because
we can implement
\[
\text{ftn}_{F}=\text{id}^{:Z\rightarrow Z}\quad.
\]
An identity function will always satisfy the laws. To obtain a full
monad, we need to implement
\[
\text{pu}_{F}:A\rightarrow Z\quad.
\]
This is possible only if we have a default value $z_{0}$ of type
$Z$. Assuming that, we set $\text{pu}_{F}\triangleq\_\rightarrow z_{0}$
and check the identity laws:
\begin{align*}
{\color{greenunder}\text{left identity law of }F:}\quad & \text{pu}_{F}^{:F^{A}\rightarrow F^{F^{A}}}\bef\text{ftn}_{F}=\text{pu}_{F}\bef\text{id}=\text{pu}_{F}\overset{?}{=}\text{id}\quad.
\end{align*}
The function $\text{pu}_{F}$ is a constant function that always returns
$z_{0}$; and yet it must be equal to the identity function. This
law can be satisfied only if the identity function of type $Z\rightarrow Z$
always returns the same value $z_{0}$. It follows that $z_{0}$ is
the only available value of the type $Z$, which means $Z\cong\bbnum 1$.
In that case, all functions become constants returning $1$, and the
laws are trivially satisfied. We conclude that the only case when
a constant functor is a lawful monad is when $L^{A}\triangleq\bbnum 1$
(the constant \lstinline!Unit! type).

The identity functor $\text{Id}^{A}\triangleq A$ is a monad: its
\lstinline!pure! and \lstinline!flatten! methods are identity functions.

Functor composition $F\circ G$ is not guaranteed to produce monads
even if $F$ and $G$ are both monads. A counterexample can be found
by taking $F^{A}\triangleq Z+A$ and $G^{A}\triangleq R\rightarrow A$;
the composition $L^{A}\triangleq Z+\left(R\rightarrow A\right)$ is
not even a semimonad.

\subsubsection{Statement \label{subsec:Statement-not-semimonad-1+r-a}\ref{subsec:Statement-not-semimonad-1+r-a}}

The functor $L^{A}\triangleq Z+\left(R\rightarrow A\right)$, where
$R$ and $Z$ are fixed but arbitrary types, cannot have a \lstinline!flatten!
method.

\subparagraph{Proof}

The type signature of \lstinline!flatten! is
\[
\text{ftn}_{L}:Z+\left(R\rightarrow Z+\left(R\rightarrow A\right)\right)\rightarrow Z+\left(R\rightarrow A\right)\quad.
\]
A fully parametric implementation is impossible: we would need to
compute either a value of type $Z$ or of type $R\rightarrow A$ from
an argument that may have either type $Z$ or type $R\rightarrow Z+\left(R\rightarrow A\right)$.
When the argument has the latter type, it is impossible to compute
either a value of type $Z$ or a value of type $R\rightarrow A$,
because different values may be returned for different values of $R$,
and we do not have any known values of type $R$ available. 

\paragraph{Products}

The product construction works for semimonads as well as for monads.

\subsubsection{Statement \label{subsec:Statement-monad-semimonad-product}\ref{subsec:Statement-monad-semimonad-product}}

Given two semimonads $F^{A}$ and $G^{A}$, the functor $L^{A}\triangleq F^{A}\times G^{A}$
is a semimonad. If both $F^{A}$and $G^{A}$ are monads then $L^{A}$
is also a monad.

\subparagraph{Proof}

Begin by defining the \lstinline!flatten! method for the semimonad
$L$ via the \lstinline!flatten! methods of $F$ and $G$. The \lstinline!flatten!
method needs to transform a value of type $L^{L^{A}}=F^{F^{A}\times G^{A}}\times G^{F^{A}\times G^{A}}$
into a value of type $F^{A}\times G^{A}$. Since $F$ and $G$ are
functors, we can extract $F^{F^{A}}$ out of $F^{F^{A}\times G^{A}}$
by lifting the standard projection function $\pi_{1}$,
\[
\pi_{1}^{\uparrow F}:F^{F^{A}\times G^{A}}\rightarrow F^{F^{A}}\quad.
\]
Then we use $F$\textsf{'}s \lstinline!flatten! method to obtain a value of
type $F^{A}$. In a similar way, we transform a value of type $G^{F^{A}\times G^{A}}$
into $G^{A}$. The resulting code is
\begin{lstlisting}
def flatten_L[A]: (F[(F[A], G[A])], G[(F[A], G[A])]) => (F[A], G[A]) = { case (fla, gla) =>
  val ffa: F[F[A]] = fla.map(_._1)
  val gga: G[G[A]] = gla.map(_._2)
  (flatten_F(ffa), flatten_G(gga))
}
\end{lstlisting}
\begin{equation}
\text{ftn}_{L}\triangleq f^{:F^{F^{A}\times G^{A}}}\times g^{:G^{F^{A}\times G^{A}}}\rightarrow\big(f\triangleright\pi_{1}^{\uparrow F}\triangleright\text{ftn}_{F}\big)\times\big(g\triangleright\pi_{2}^{\uparrow G}\triangleright\text{ftn}_{G}\big)=(\pi_{1}^{\uparrow F}\bef\text{ftn}_{F})\boxtimes(\pi_{2}^{\uparrow G}\bef\text{ftn}_{G})\quad.\label{eq:monad-product-flatten-def-ftn}
\end{equation}
To verify the associativity law, we need to write the code of $\text{ftn}_{L}^{\uparrow L}$:
\[
(h^{:A\rightarrow B})^{\uparrow L}=h^{\uparrow F}\boxtimes h^{\uparrow G}\quad,\quad\quad\text{ftn}_{L}^{\uparrow L}=\text{ftn}_{L}^{\uparrow F}\boxtimes\text{ftn}_{L}^{\uparrow G}\quad.
\]
Substitute these definitions into the associativity law:
\begin{align*}
{\color{greenunder}\text{left-hand side}:}\quad & \text{ftn}_{L}^{\uparrow L}\bef\text{ftn}_{L}=\big(\text{ftn}_{L}^{\uparrow F}\boxtimes\text{ftn}_{L}^{\uparrow G}\big)\bef\big((\pi_{1}^{\uparrow F}\bef\text{ftn}_{F})\boxtimes(\pi_{2}^{\uparrow G}\bef\text{ftn}_{G})\big)\\
{\color{greenunder}\text{use Eq.~(\ref{eq:pair-product-composition-law})}:}\quad & \quad=\big(\text{ftn}_{L}^{\uparrow F}\bef\pi_{1}^{\uparrow F}\bef\text{ftn}_{F}\big)\boxtimes\big(\text{ftn}_{L}^{\uparrow G}\bef\pi_{2}^{\uparrow G}\bef\text{ftn}_{G}\big)\quad,\\
{\color{greenunder}\text{right-hand side}:}\quad & \text{ftn}_{L}\bef\text{ftn}_{L}=\big((\pi_{1}^{\uparrow F}\bef\text{ftn}_{F})\boxtimes(\pi_{2}^{\uparrow G}\bef\text{ftn}_{G})\big)\bef\big((\pi_{1}^{\uparrow F}\bef\text{ftn}_{F})\boxtimes(\pi_{2}^{\uparrow G}\bef\text{ftn}_{G})\big)\\
{\color{greenunder}\text{use Eq.~(\ref{eq:pair-product-composition-law})}:}\quad & \quad=\big(\pi_{1}^{\uparrow F}\bef\text{ftn}_{F}\bef\pi_{1}^{\uparrow F}\bef\text{ftn}_{F}\big)\boxtimes\big(\pi_{2}^{\uparrow G}\bef\text{ftn}_{G}\bef\pi_{2}^{\uparrow G}\bef\text{ftn}_{G}\big)\quad.
\end{align*}
The only given information about $\text{ftn}_{F}$ and $\text{ftn}_{G}$
is that they obey their associativity laws; e.g.,
\[
\text{ftn}_{F}^{\uparrow F}\bef\text{ftn}_{F}=\text{ftn}_{F}\bef\text{ftn}_{F}\quad.
\]
In order to use this law, we need to move the two functions $\text{ftn}_{F}$
next to each other in the expressions 
\[
\big(\text{ftn}_{L}^{\uparrow F}\bef\pi_{1}^{\uparrow F}\bef\text{ftn}_{F}\big)\quad\text{ and }\quad\big(\pi_{1}^{\uparrow F}\bef\text{ftn}_{F}\bef\pi_{1}^{\uparrow F}\bef\text{ftn}_{F}\big)\quad,
\]
hoping to show that these expressions are equal. We begin with the
first of those expressions:
\begin{align*}
 & \gunderline{\text{ftn}_{L}^{\uparrow F}\bef\pi_{1}^{\uparrow F}}\bef\text{ftn}_{F}=\big(\gunderline{\text{ftn}_{L}\bef\pi_{1}}\big)^{\uparrow F}\bef\text{ftn}_{F}\\
{\color{greenunder}\text{left projection law~(\ref{eq:pair-product-projection-laws})}:}\quad & =\big(\pi_{1}\bef\pi_{1}^{\uparrow F}\bef\text{ftn}_{F}\big)^{\uparrow F}\bef\text{ftn}_{F}=\pi_{1}^{\uparrow F}\bef\pi_{1}^{\uparrow F\uparrow F}\bef\gunderline{\text{ftn}_{F}^{\uparrow F}\bef\text{ftn}_{F}}\\
{\color{greenunder}\text{associativity law of }F:}\quad & =\pi_{1}^{\uparrow F}\bef\gunderline{\pi_{1}^{\uparrow F\uparrow F}\bef\text{ftn}_{F}}\bef\text{ftn}_{F}\\
{\color{greenunder}\text{naturality law of }\text{ftn}_{F}:}\quad & =\pi_{1}^{\uparrow F}\bef\gunderline{\text{ftn}_{F}\bef\pi_{1}^{\uparrow F}}\bef\text{ftn}_{F}\quad.
\end{align*}
Both expressions are now the same. An analogous derivation shows that
\[
\text{ftn}_{L}^{\uparrow G}\bef\pi_{2}^{\uparrow G}\bef\text{ftn}_{G}=\pi_{2}^{\uparrow G}\bef\text{ftn}_{G}\bef\pi_{2}^{\uparrow G}\bef\text{ftn}_{G}\quad.
\]
So, both sides of the associativity law are equal.

Now we assume that $F$ and $G$ are monads with given \lstinline!pure!
methods $\text{pu}_{F}$ and $\text{pu}_{G}$. We define
\[
\text{pu}_{L}\triangleq a^{:A}\rightarrow\text{pu}_{F}(a)\times\text{pu}_{G}(a)=\Delta\bef(\text{pu}_{F}\boxtimes\text{pu}_{G})\quad.
\]
Assuming that identity laws hold for $F$ and $G$, we can now verify
the identity laws for $L$:
\begin{align*}
{\color{greenunder}\text{left identity law of }L:}\quad & \text{pu}_{L}\bef\text{ftn}_{L}=\Delta\bef(\text{pu}_{F}\boxtimes\text{pu}_{G})\bef\big((\pi_{1}^{\uparrow F}\bef\text{ftn}_{F})\boxtimes(\pi_{2}^{\uparrow G}\bef\text{ftn}_{G})\big)\\
{\color{greenunder}\text{use Eq.~(\ref{eq:pair-product-composition-law})}:}\quad & \quad=\Delta\bef\big((\gunderline{\text{pu}_{F}\bef\pi_{1}^{\uparrow F}}\bef\text{ftn}_{F})\boxtimes(\gunderline{\text{pu}_{G}\bef\pi_{2}^{\uparrow G}}\bef\text{ftn}_{G})\big)\\
{\color{greenunder}\text{naturality of }F,G:}\quad & \quad=\Delta\bef\big((\pi_{1}\bef\gunderline{\text{pu}_{F}\bef\text{ftn}_{F}})\boxtimes(\pi_{2}\bef\gunderline{\text{pu}_{G}\bef\text{ftn}_{G}})\big)\\
{\color{greenunder}\text{identity laws of }F,G:}\quad & \quad=\Delta\bef(\pi_{1}\times\pi_{2})=\text{id}\quad,\\
{\color{greenunder}\text{right identity law of }L:}\quad & \text{pu}_{L}^{\uparrow L}\bef\text{ftn}_{L}=\big(\big(\Delta\bef(\text{pu}_{F}\boxtimes\text{pu}_{G})\big)^{\uparrow F}\boxtimes\big(\Delta\bef(\text{pu}_{F}\boxtimes\text{pu}_{G})\big)^{\uparrow G}\big)\bef\text{ftn}_{L}\\
{\color{greenunder}\text{use Eq.~(\ref{eq:pair-product-composition-law})}:}\quad & \quad=\big(\big(\Delta\bef\gunderline{(\text{pu}_{F}\boxtimes\text{pu}_{G})\big)^{\uparrow F}\bef\pi_{1}^{\uparrow F}}\bef\text{ftn}_{F}\big)\boxtimes\big(\big(\Delta\bef\gunderline{(\text{pu}_{F}\boxtimes\text{pu}_{G})\big)^{\uparrow G}\bef\pi_{2}^{\uparrow G}}\bef\text{ftn}_{G}\big)\\
{\color{greenunder}\text{projection laws~(\ref{eq:pair-product-projection-laws})}:}\quad & \quad=\big((\gunderline{\Delta\bef\pi_{1}}\bef\text{pu}_{F})^{\uparrow F}\bef\text{ftn}_{F}\big)\boxtimes\big(\big(\gunderline{\Delta\bef\pi_{2}}\bef\text{pu}_{G}\big)^{\uparrow G}\bef\text{ftn}_{G}\big)\\
{\color{greenunder}\text{identity laws~(\ref{eq:pair-identity-law-left})}:}\quad & \quad=\big(\gunderline{\text{pu}_{F}^{\uparrow F}\bef\text{ftn}_{F}}\big)\boxtimes\big(\gunderline{\text{pu}_{G}^{\uparrow G}\bef\text{ftn}_{G}}\big)=\text{id}\boxtimes\text{id}=\text{id}\quad.
\end{align*}

Let us build some intuition about how the product of two monads works
in practice. A simple example is the product of two identity monads,
$L^{A}\triangleq A\times A$. This type constructor is a monad whose
\lstinline!flatten! function is defined by
\begin{lstlisting}
type Pair[A] = (A, A)
def flatten[A]: Pair[Pair[A]] => Pair[A] = { case ((a, b), (c, d)) => (a, d) }
\end{lstlisting}
A sample calculation shows that \textsf{``}nested iterations\textsf{''} apply functions
element by element:
\begin{lstlisting}
final case class P[A](x: A, y: A) {
  def map[B](f: A => B): P[B] = P(f(x), f(y))
  def flatMap[B](f: A => P[B]): P[B] = P(f(x).x, f(y).y)
}

scala> for {
  x <- P(1, 10)
  y <- P(2, 20)
  z <- P(3, 30)
} yield x + y + z       // The result is P(1 + 2 + 3, 10 + 20 + 30).
res0: P[Int] = P(6, 60)
\end{lstlisting}

Note that the pair type $A\times A$ is equivalent to the function
type $\bbnum 2\rightarrow A$ (in Scala, \lstinline!Boolean => A!).
We know that $\bbnum 2\rightarrow A$ is a \lstinline!Reader! monad.
One can check that the implementation of \lstinline!flatten! for
the \lstinline!Reader! monad $\bbnum 2\rightarrow A$ is equivalent
to the code of \lstinline!flatten! for $L^{A}\triangleq A\times A$
as shown above.

Now consider the product $F^{A}\times G^{A}$ with arbitrary monads
$F$ and $G$ that represent some effects. Then a Kleisli function
of type $A\rightarrow F^{B}\times G^{B}$ contains both effects. How
does the monad $L$ combine two effects when we compose two such Kleisli
functions? We see from the code of $L$\textsf{'}s \lstinline!flatten! that
the first effect in $F$ is combined with the second effect in $F$,
and the first effect in $G$ is combined with the second effect in
$G$. The part $F^{G^{A}}$ from $F^{F^{A}\times G^{A}}$ is discarded
by \lstinline!flatten!, leaving only $F^{F^{A}}$, i.e., a combination
of two $F$-effects. Also, $G^{F^{A}}$ is discarded from $G^{F^{A}\times G^{A}}$,
leaving only $G^{G^{A}}$. As an example, consider this code:
\begin{lstlisting}
val result: (F[C], G[C]) = for {
  x <- (fa, ga)          // Assume fa: F[A], ga: G[A]
  y <- (fb, gb)          // Assume fb: F[B], gb: G[B]
} yield h(x, y)          // Assume h: (A, B) => C
\end{lstlisting}
The expression \lstinline!result! is equivalent to the following
code that works with $F$ and $G$ separately:\vspace{-0.95\baselineskip}

\begin{center}
\begin{minipage}[t]{0.3\columnwidth}%
\begin{lstlisting}
val result1: F[C] = for {
  x <- fa
  y <- fb
} yield h(x, y)
\end{lstlisting}
%
\end{minipage}\hfill{} %
\begin{minipage}[t]{0.3\columnwidth}%
\begin{lstlisting}
val result2: G[C] = for {
  x <- ga
  y <- gb
} yield h(x, y)
\end{lstlisting}
%
\end{minipage}\hfill{} %
\begin{minipage}[t]{0.3\columnwidth}%
\begin{lstlisting}
val result: (F[C], G[C]) =
  (result1, result2)
\end{lstlisting}
%
\end{minipage}\vspace{-0.35\baselineskip}
\par\end{center}

A composition of two $L$-effects is a pair consisting of $F$-effects
and $G$-effects composed separately. Because of that, the composition
of $L$-effects is associative (and so $L$ is a lawful semimonad)
as long as $F$- and $G$-effects are themselves composed associatively.

\subsubsection{Statement \label{subsec:Statement-semimonad-only-product-a-ga}\ref{subsec:Statement-semimonad-only-product-a-ga}}

Given any functor $F$, the functor $L^{A}\triangleq A\times F^{A}$
is a semimonad.

\subparagraph{Proof}

We begin by implementing the \lstinline!flatten! method for $L$,
with the type signature $A\times F^{A}\times F^{A\times F^{A}}\rightarrow A\times F^{A}$.
Since we know nothing about the functor $F$, we cannot extract values
of type $A$ from $F^{A}$. We also do not have a \lstinline!flatten!
method for $F$. How can we get values of type $A$ and $F^{A}$ out
of $A\times F^{A}\times F^{A\times F^{A}}$? One possibility is simply
to discard the part of type $F^{A\times F^{A}}$:
\begin{lstlisting}
def flatten1_L[A]: ((A, F[A]), F[(A, F[A])]) => (A, F[A]) = _._1
\end{lstlisting}
The other possibility is to transform $F^{A\times F^{A}}$ to $F^{A}$
within the functor $F$:
\begin{lstlisting}
def flatten2_L[A]: ((A, F[A]), F[(A, F[A])]) => (A, F[A]) = { case (afa, fafa) =>
  (afa._1, fafa.map(_._1))
}
\end{lstlisting}
In the code notation, these alternative implementations may be written
as
\[
\text{ftn}_{1\,L}\triangleq\pi_{1}=p^{:A\times F^{A}}\times q^{:F^{A\times F^{A}}}\rightarrow p\quad,\quad\text{ftn}_{2\,L}\triangleq p^{:A\times F^{A}}\times q^{:F^{A\times F^{A}}}\rightarrow\big(p\triangleright\pi_{1}\big)\times\big(q\triangleright\pi_{1}^{\uparrow F}\big)=\pi_{1}\boxtimes\pi_{1}^{\uparrow F}\quad.
\]

To check the associativity laws, we need to prepare the code for lifting
to the functor $L$:
\[
f^{\uparrow L}=f\boxtimes f^{\uparrow F}\quad,\quad\quad\text{ftn}_{1\,L}^{\uparrow L}=\pi_{1}\boxtimes\pi_{1}^{\uparrow F}\quad,\quad\quad\text{ftn}_{2\,L}^{\uparrow L}=(\pi_{1}\boxtimes\pi_{1}^{\uparrow F})\boxtimes(\pi_{1}\boxtimes\pi_{1}^{\uparrow F})^{\uparrow F}\quad.
\]
Then we verify the associativity law for $\text{ftn}_{1\,L}$ using
the projection law~(\ref{eq:pair-product-projection-laws}): 
\begin{align*}
{\color{greenunder}\text{left-hand side}:}\quad & \text{ftn}_{1\,L}^{\uparrow L}\bef\text{ftn}_{1\,L}=(\pi_{1}\boxtimes\pi_{1}^{\uparrow F})\bef\pi_{1}=\pi_{1}\bef\pi_{1}\quad,\\
{\color{greenunder}\text{right-hand side}:}\quad & \text{ftn}_{1\,L}\bef\text{ftn}_{1\,L}=\pi_{1}\bef\pi_{1}\quad.
\end{align*}
The law holds. For $\text{ftn}_{2\,L}$, we also find that the two
sides of the law are equal:
\begin{align*}
 & \text{ftn}_{2\,L}^{\uparrow L}\bef\text{ftn}_{2\,L}=\big((\pi_{1}\boxtimes\pi_{1}^{\uparrow F})\boxtimes(\pi_{1}\boxtimes\pi_{1}^{\uparrow F})^{\uparrow F}\big)\bef(\pi_{1}\boxtimes\pi_{1}^{\uparrow F})\\
{\color{greenunder}\text{use Eq.~(\ref{eq:pair-product-composition-law})}:}\quad & \quad=\big((\pi_{1}\boxtimes\pi_{1}^{\uparrow F})\bef\pi_{1}\big)\boxtimes\big(\gunderline{(\pi_{1}\boxtimes\pi_{1}^{\uparrow F})^{\uparrow F}\bef\pi_{1}^{\uparrow F}}\big)=\big(\gunderline{(\pi_{1}\boxtimes\pi_{1}^{\uparrow F})\bef\pi_{1}}\big)\boxtimes\big(\gunderline{(\pi_{1}\boxtimes\pi_{1}^{\uparrow F})\bef\pi_{1}}\big)^{\uparrow F}\\
{\color{greenunder}\text{use Eq.~(\ref{eq:pair-product-projection-laws})}:}\quad & \quad=(\pi_{1}\bef\pi_{1})\boxtimes(\pi_{1}\bef\pi_{1})^{\uparrow F}=(\pi_{1}\bef\pi_{1})\boxtimes(\pi_{1}^{\uparrow F}\bef\pi_{1}^{\uparrow F})\quad,\\
 & \text{ftn}_{2\,L}\bef\text{ftn}_{2\,L}=(\pi_{1}\boxtimes\pi_{1}^{\uparrow F})\bef(\pi_{1}\boxtimes\pi_{1}^{\uparrow F})=(\pi_{1}\bef\pi_{1})\boxtimes(\pi_{1}^{\uparrow F}\bef\pi_{1}^{\uparrow F})\quad.
\end{align*}

So, both implementations ($\text{ftn}_{2\,L}$ and $\text{ftn}_{2\,L}$)
are associative. Those implementations of \lstinline!flatten! discard
either the first $F$-effect or the second one. Since all implementations
of \lstinline!flatten! discard effects, identity laws cannot hold,
and so the semimonads of the form $L^{A}\triangleq A\times F^{A}$
are not monads. A semimonad $L$ combines $F$-effects similarly to
the \textsf{``}trivial\textsf{''} semigroup (see Section~\ref{subsec:Semigroups-constructions})
whose binary operation simply discards the left or the right argument.
Such semigroups cannot be made into monoids since the identity laws
will not hold. This construction illustrates the connections between
monoids, semigroups, monads, and semimonads.

\paragraph{Co-products}

As a rule, the co-product of two monads ($F^{A}+G^{A}$) is not a
monad. For simple examples, see Exercise~\ref{subsec:Exercise-1-monads-6}
for $\bbnum 1+F^{A}$ (where $F^{A}\triangleq A\times A$) and Exercise~\ref{subsec:Exercise-1-monads-4}
for $M^{A}+M^{A}$ with an arbitrary monad $M$. An exception to that
rule is a co-product with the \emph{identity} monad:

\subsubsection{Statement \label{subsec:Statement-co-product-with-identity-monad}\ref{subsec:Statement-co-product-with-identity-monad}}

If $F$ is any monad, the functor $L^{A}\triangleq A+F^{A}$ is a
monad. (The functor $L$ is called the \textbf{free pointed}\index{free pointed monad}\index{monads!free pointed}\index{free pointed functor}
\textbf{functor on} $F$, for reasons explained in Chapter~\ref{chap:Free-type-constructions}.)

\subparagraph{Proof}

We need to define the monad methods for $L$, for which we may use
the \lstinline!pure! and \lstinline!flatten! methods of $F$. Begin
with the \lstinline!flatten! method, which needs to have the type
signature
\[
\text{ftn}_{L}:L^{L^{A}}\rightarrow L^{A}=A+F^{A}+F^{A+F^{A}}\rightarrow A+F^{A}\quad.
\]
Since we know nothing about the specific monad $F$, we cannot extract
a value of type $A$ out of $F^{A}$. However, we can use $F$\textsf{'}s \lstinline!pure!
method to create a value of type $F^{A}$ out of $A$. This allows
us to convert $A+F^{A}$ into $F^{A}$ using the function we will
denote $\gamma$:

\begin{wrapfigure}{l}{0.55\columnwidth}%
\vspace{-0.8\baselineskip}
\begin{lstlisting}
type L[A] = Either[A, F[A]]
def gamma[A]: L[A] => F[A] = {
  case Left(a)   => F.pure(a)
  case Right(fa) => fa
}
\end{lstlisting}

\vspace{-2\baselineskip}
\end{wrapfigure}%

~\vspace{-0.2\baselineskip}
\[
\gamma^{A}\triangleq\,\begin{array}{|c||c|}
 & F^{A}\\
\hline A & \text{pu}_{F}\\
F^{A} & \text{id}
\end{array}\quad.
\]

\noindent Lifting this function to $F$, we can convert $F^{A+F^{A}}$
into $F^{F^{A}}$ and finally into $F^{A}$ via $F$\textsf{'}s \lstinline!flatten!
method:

\begin{wrapfigure}{l}{0.55\columnwidth}%
\vspace{-0.5\baselineskip}
\begin{lstlisting}
def flatten_L[A]: L[L[A]] => L[A] = {
  case Left(Left(a))   => Left(a)
  case Left(Right(fa)) => Right(fa)
  case Right(g)        => Right(g.map(gamma).flatten)
}  // The last line equals `Right(g.flatMap(gamma))`.
\end{lstlisting}

\vspace{-3\baselineskip}
\end{wrapfigure}%

~\vspace{-1.1\baselineskip}
\[
\text{ftn}_{L}\triangleq\,\begin{array}{|c||cc|}
 & A & F^{A}\\
\hline A & \text{id} & \bbnum 0\\
F^{A} & \bbnum 0 & \text{id}\\
F^{L^{A}} & \bbnum 0 & \gamma^{\uparrow F}\bef\text{ftn}_{F}
\end{array}\quad.
\]

Is there another implementation for $\text{ftn}_{L}$? We could have
replaced $A$ by $F^{A}$ using $\text{pu}_{F}$. However, that code
would never return a result of type $A+\bbnum 0$, which makes it
impossible to satisfy identity laws such as $\text{pu}_{F}\bef\text{ftn}_{F}=\text{id}$.

The \lstinline!pure! method for $L$ could be defined in two ways:
$\text{pu}_{L}\triangleq a^{:A}\rightarrow a+\bbnum 0$ or $\text{pu}_{L}\triangleq a\rightarrow\bbnum 0+\text{pu}_{F}(a)$.
It turns out that only the first definition satisfies the monad $L$\textsf{'}s
identity laws (Exercise~\ref{subsec:Exercise-1-monads-12}).

To verify the identity laws for the definition $\text{pu}_{L}\triangleq a^{:A}\rightarrow a+\bbnum 0$,
begin by writing the lifting code for the functor $L$ and a fully
split matrix for $\text{pu}_{L}^{\uparrow L}$,
\[
(f^{:A\rightarrow B})^{\uparrow L}=\,\begin{array}{|c||cc|}
 & B & F^{B}\\
\hline A & f & \bbnum 0\\
F^{A} & \bbnum 0 & f^{\uparrow F}
\end{array}\quad,\quad\quad\text{pu}_{L}^{\uparrow L}=\,\begin{array}{|c||cc|}
 & L^{A} & F^{L^{A}}\\
\hline A & \text{pu}_{L} & \bbnum 0\\
F^{A} & \bbnum 0 & \text{pu}_{L}^{\uparrow F}
\end{array}\,=\,\begin{array}{|c||ccc|}
 & A & F^{A} & F^{L^{A}}\\
\hline A & \text{id} & \bbnum 0 & \bbnum 0\\
F^{A} & \bbnum 0 & \bbnum 0 & \text{pu}_{L}^{\uparrow F}
\end{array}\quad.
\]
Then write the two identity laws and simplify using matrix compositions:
\[
\text{pu}_{L}^{L^{A}}\bef\text{ftn}_{L}=\,\begin{array}{|c||ccc|}
 & A & F^{A} & F^{L^{A}}\\
\hline A & \text{id} & \bbnum 0 & \bbnum 0\\
F^{A} & \bbnum 0 & \text{id} & \bbnum 0
\end{array}\,\bef\,\begin{array}{|c||cc|}
 & A & F^{A}\\
\hline A & \text{id} & \bbnum 0\\
F^{A} & \bbnum 0 & \text{id}\\
F^{L^{A}} & \bbnum 0 & \gamma^{\uparrow F}\bef\text{ftn}_{F}
\end{array}\,=\,\begin{array}{|c||cc|}
 & A & F^{A}\\
\hline A & \text{id} & \bbnum 0\\
F^{A} & \bbnum 0 & \text{id}
\end{array}\,=\text{id}\quad,
\]
\[
\text{pu}_{L}^{\uparrow L}\bef\text{ftn}_{L}=\,\begin{array}{|c||ccc|}
 & A & F^{A} & F^{L^{A}}\\
\hline A & \text{id} & \bbnum 0 & \bbnum 0\\
F^{A} & \bbnum 0 & \bbnum 0 & \text{pu}_{L}^{\uparrow F}
\end{array}\,\bef\,\begin{array}{|c||cc|}
 & A & F^{A}\\
\hline A & \text{id} & \bbnum 0\\
F^{A} & \bbnum 0 & \text{id}\\
F^{L^{A}} & \bbnum 0 & \gamma^{\uparrow F}\bef\text{ftn}_{F}
\end{array}\,=\,\begin{array}{|c||cc|}
 & A & F^{A}\\
\hline A & \text{id} & \bbnum 0\\
F^{A} & \bbnum 0 & \text{pu}_{L}^{\uparrow F}\bef\gamma^{\uparrow F}\bef\text{ftn}_{F}
\end{array}\quad.
\]
We will show that the last matrix equals identity by proving that
\[
\text{id}\overset{?}{=}\text{pu}_{L}^{\uparrow F}\bef\gamma^{\uparrow F}\bef\text{ftn}_{F}=(\text{pu}_{L}\bef\gamma)^{\uparrow F}\bef\text{ftn}_{F}\quad.
\]
Let us simplify the function $\text{pu}_{L}\bef\gamma$ in a separate
calculation:
\[
\text{pu}_{L}\bef\gamma=\,\begin{array}{|c||cc|}
 & A & F^{A}\\
\hline A & \text{id} & \bbnum 0
\end{array}\,\bef\,\begin{array}{|c||c|}
 & F^{A}\\
\hline A & \text{pu}_{F}\\
F^{A} & \text{id}
\end{array}\,=\text{pu}_{F}\quad.
\]
It remains to show that
\[
\text{id}\overset{?}{=}(\text{pu}_{L}\bef\gamma)^{\uparrow F}\bef\text{ftn}_{F}=\text{pu}_{F}^{\uparrow F}\bef\text{ftn}_{F}\quad.
\]
But this is the right identity law of the monad $F$, which (by assumption)
is a lawful monad. 

The next step is to verify the associativity law for $L$. Write the
code for $\text{ftn}_{L}^{\uparrow L}$ and $\text{ftn}_{L}^{L^{A}}$:
\begin{align*}
 & \text{ftn}_{L}^{\uparrow L}=\,\begin{array}{|c||cc|}
 & L^{A} & F^{L^{A}}\\
\hline L^{L^{A}} & \text{ftn}_{L} & \bbnum 0\\
F^{L^{L^{A}}} & \bbnum 0 & \text{ftn}_{L}^{\uparrow F}
\end{array}\,=\,\begin{array}{|c||ccc|}
 & A & F^{A} & F^{L^{A}}\\
\hline A & \text{id} & \bbnum 0 & \bbnum 0\\
F^{A} & \bbnum 0 & \text{id} & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \gamma^{\uparrow F}\bef\text{ftn}_{F} & \bbnum 0\\
F^{L^{L^{A}}} & \bbnum 0 & \bbnum 0 & \text{ftn}_{L}^{\uparrow F}
\end{array}\quad,
\end{align*}
\begin{align*}
 & \text{ftn}_{L}^{L^{A}}=\,\begin{array}{|c||cc|}
 & L^{A} & F^{L^{A}}\\
\hline L^{A} & \text{id} & \bbnum 0\\
F^{L^{a}} & \bbnum 0 & \text{id}\\
F^{L^{L^{A}}} & \bbnum 0 & \gamma^{\uparrow F}\bef\text{ftn}_{F}
\end{array}\,=\,\begin{array}{|c||ccc|}
 & A & F^{A} & F^{L^{A}}\\
\hline A & \text{id} & \bbnum 0 & \bbnum 0\\
F^{A} & \bbnum 0 & \text{id} & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \bbnum 0 & \text{id}\\
F^{L^{L^{A}}} & \bbnum 0 & \bbnum 0 & \gamma^{\uparrow F}\bef\text{ftn}_{F}
\end{array}\quad.
\end{align*}
We are ready to verify the associativity law. Simplify both sides
using matrix compositions:
\[
\negthickspace\negthickspace\negthickspace\negthickspace\text{ftn}_{L}^{\uparrow L}\bef\text{ftn}_{L}=\,\begin{array}{|c||ccc|}
 & A & F^{A} & F^{L^{A}}\\
\hline A & \text{id} & \bbnum 0 & \bbnum 0\\
F^{A} & \bbnum 0 & \text{id} & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \gamma^{\uparrow F}\bef\text{ftn}_{F} & \bbnum 0\\
F^{L^{L^{A}}} & \bbnum 0 & \bbnum 0 & \text{ftn}_{L}^{\uparrow F}
\end{array}\,\bef\,\begin{array}{|c||cc|}
 & A & F^{A}\\
\hline A & \text{id} & \bbnum 0\\
F^{A} & \bbnum 0 & \text{id}\\
F^{L^{A}} & \bbnum 0 & \gamma^{\uparrow F}\bef\text{ftn}_{F}
\end{array}\,=\,\begin{array}{|c||cc|}
 & A & F^{A}\\
\hline A & \text{id} & \bbnum 0\\
F^{A} & \bbnum 0 & \text{id}\\
F^{L^{A}} & \bbnum 0 & \gamma^{\uparrow F}\bef\text{ftn}_{F}\\
F^{L^{L^{A}}} & \bbnum 0 & \text{ftn}_{L}^{\uparrow F}\bef\gamma^{\uparrow F}\bef\text{ftn}_{F}
\end{array}\quad,
\]
\[
\negthickspace\negthickspace\negthickspace\negthickspace\text{ftn}_{L}^{L^{A}}\bef\text{ftn}_{L}=\,\begin{array}{|c||ccc|}
 & A & F^{A} & F^{L^{A}}\\
\hline A & \text{id} & \bbnum 0 & \bbnum 0\\
F^{A} & \bbnum 0 & \text{id} & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \bbnum 0 & \text{id}\\
F^{L^{L^{A}}} & \bbnum 0 & \bbnum 0 & \gamma^{\uparrow F}\bef\text{ftn}_{F}
\end{array}\,\bef\,\begin{array}{|c||cc|}
 & A & F^{A}\\
\hline A & \text{id} & \bbnum 0\\
F^{A} & \bbnum 0 & \text{id}\\
F^{L^{A}} & \bbnum 0 & \gamma^{\uparrow F}\bef\text{ftn}_{F}
\end{array}\,=\,\begin{array}{|c||cc|}
 & A & F^{A}\\
\hline A & \text{id} & \bbnum 0\\
F^{A} & \bbnum 0 & \text{id}\\
F^{L^{A}} & \bbnum 0 & \gamma^{\uparrow F}\bef\text{ftn}_{F}\\
F^{L^{L^{A}}} & \bbnum 0 & \gamma^{\uparrow F}\bef\text{ftn}_{F}\bef\gamma^{\uparrow F}\bef\text{ftn}_{F}
\end{array}\quad.
\]
We will show that the last matrices are equal if we can prove equality
of the expressions
\[
\text{ftn}_{L}^{\uparrow F}\bef\gamma^{\uparrow F}\bef\text{ftn}_{F}\overset{?}{=}\gamma^{\uparrow F}\bef\text{ftn}_{F}\bef\gamma^{\uparrow F}\bef\text{ftn}_{F}\quad,
\]
which are functions of type $F^{L^{L^{A}}}\rightarrow F^{A}$. Simplify
these expressions separately:
\begin{align*}
{\color{greenunder}\text{left-hand side}:}\quad & \text{ftn}_{L}^{\uparrow F}\bef\gamma^{\uparrow F}\bef\text{ftn}_{F}=\big(\text{ftn}_{L}\bef\gamma\big)^{\uparrow F}\bef\text{ftn}_{F}\quad,\\
{\color{greenunder}\text{right-hand side}:}\quad & \gamma^{\uparrow F}\bef\gunderline{\text{ftn}_{F}\bef\gamma^{\uparrow F}}\bef\text{ftn}_{F}\\
{\color{greenunder}\text{naturality of }\text{ftn}_{F}:}\quad & \quad=\gamma^{\uparrow F}\bef\gamma^{\uparrow F\uparrow F}\bef\gunderline{\text{ftn}_{F}\bef\text{ftn}_{F}}\\
{\color{greenunder}\text{associativity law of }F:}\quad & \quad=\gunderline{\gamma^{\uparrow F}\bef\gamma^{\uparrow F\uparrow F}\bef\text{ftn}_{F}^{\uparrow F}}\bef\text{ftn}_{F}=\big(\gamma\bef\gamma^{\uparrow F}\bef\text{ftn}_{F}\big)^{\uparrow F}\bef\text{ftn}_{F}\quad.
\end{align*}
It remains to show the equality of the functions under $\big(...\big)^{\uparrow F}$:
\begin{equation}
\text{ftn}_{L}\bef\gamma\overset{?}{=}\gunderline{\gamma\bef\gamma^{\uparrow F}}\bef\text{ftn}_{F}=\gamma^{\uparrow L}\bef\gamma\bef\text{ftn}_{F}\quad,\label{eq:monad-construction-a+f-a-derivation1}
\end{equation}
where in the last step we used the naturality law of $\gamma^{:L^{^{A}}\rightarrow F^{A}}$,
which is a natural transformation:
\[
\gamma\bef f^{\uparrow F}=f^{\uparrow L}\bef\gamma\quad,\quad\text{for all }f^{:A\rightarrow B}\quad.
\]
The functions in Eq.~(\ref{eq:monad-construction-a+f-a-derivation1})
are equal due to $F$\textsf{'}s identity law ($\text{pu}_{F}\bef\text{ftn}_{F}=\text{id}$):
\begin{align*}
 & \text{ftn}_{L}\bef\gamma=\,\begin{array}{|c||cc|}
 & A & F^{A}\\
\hline A & \text{id} & \bbnum 0\\
F^{A} & \bbnum 0 & \text{id}\\
F^{L^{A}} & \bbnum 0 & \gamma^{\uparrow F}\bef\text{ftn}_{F}
\end{array}\,\bef\,\begin{array}{|c||c|}
 & F^{A}\\
\hline A & \text{pu}_{F}\\
F^{A} & \text{id}
\end{array}\,=\,\begin{array}{|c||c|}
 & F^{A}\\
\hline A & \text{pu}_{F}\\
F^{A} & \text{id}\\
F^{L^{A}} & \gamma^{\uparrow F}\bef\text{ftn}_{F}
\end{array}\,=\,\begin{array}{|c||c|}
 & F^{A}\\
\hline L^{A} & \gamma\\
F^{L^{A}} & \gamma^{\uparrow F}\bef\text{ftn}_{F}
\end{array}\quad,
\end{align*}
\begin{align*}
 & \negthickspace\negthickspace\negthickspace\negthickspace\gamma^{\uparrow L}\bef\gamma\bef\text{ftn}_{F}=\,\begin{array}{|c||cc|}
 & F^{A} & F^{F^{A}}\\
\hline L^{A} & \gamma & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \gamma^{\uparrow F}
\end{array}\,\bef\,\begin{array}{|c||c|}
 & F^{F^{A}}\\
\hline F^{A} & \text{pu}_{F}\\
F^{F^{A}} & \text{id}
\end{array}\,\bef\text{ftn}_{F}=\,\begin{array}{|c||c|}
 & F^{A}\\
\hline L^{A} & \gamma\bef\gunderline{\text{pu}_{F}\bef\text{ftn}_{F}}\\
F^{L^{A}} & \gamma^{\uparrow F}\bef\text{id}\bef\text{ftn}_{F}
\end{array}\,=\,\begin{array}{|c||c|}
 & F^{A}\\
\hline L^{A} & \gamma\\
F^{L^{A}} & \gamma^{\uparrow F}\bef\text{ftn}_{F}
\end{array}\quad.
\end{align*}
This concludes the proof.

\paragraph{Function types}

If $F$ is a monad, can we find a type constructor $H$ such that
$L^{A}\triangleq H^{A}\rightarrow F^{A}$ is a monad? In order for
$L$ to be a functor, $H$ must be a contrafunctor. We have already
seen that $Z\rightarrow A$ is a monad (a \lstinline!Reader!) when
$Z$ is a fixed type. The type expression $Z\rightarrow A$ is indeed
of the form $H^{A}\rightarrow F^{A}$ if the type constructors are
set to $H^{A}\triangleq Z$ and $F^{A}\triangleq A$. The following
statements show two generalizations of the \lstinline!Reader! monad
to other $H$ and $F$.

\subsubsection{Statement \label{subsec:Statement-monad-construction-1}\ref{subsec:Statement-monad-construction-1}}

For a fixed type $Z$, if a functor $F$ is a (semi)monad then so
is $L^{A}\triangleq Z\rightarrow F^{A}$.

\subparagraph{Proof}

As with other monads of function type, derivations are made shorter
by using the flipped Kleisli trick. We assume that $F$\textsf{'}s Kleisli
composition $\diamond_{_{F}}$ is known and obeys the associativity
law. When $F$ is a monad, we also assume that its pure method $\text{pu}_{F}$
is known and obeys the identity laws. For the monad $L$, we will
now define the \index{flipped@\textsf{``}flipped Kleisli\textsf{''} technique}flipped
Kleisli composition $\tilde{\diamond}_{_{L}}$ and prove its laws.

The ordinary Kleisli functions have types $A\rightarrow Z\rightarrow F^{B}$,
so the flipped Kleisli functions have types $Z\rightarrow A\rightarrow F^{B}$.
We begin by defining the flipped Kleisli composition $\tilde{\diamond}_{_{L}}$
and the flipped method $\tilde{\text{pu}}_{L}$ that has type $Z\rightarrow A\rightarrow F^{A}$
(note that we use the \emph{non-flipped} methods $\diamond_{_{F}}$
and $\text{pu}_{F}$ of the monad $F$):
\begin{align*}
 & f^{:Z\rightarrow A\rightarrow F^{B}}\tilde{\diamond}_{_{L}}g^{:Z\rightarrow B\rightarrow F^{C}}\triangleq z^{:Z}\rightarrow f(z)\diamond_{_{F}}g(z)\quad,\\
 & \tilde{\text{pu}}_{L}\triangleq\_^{:Z}\rightarrow\text{pu}_{F}\quad.
\end{align*}
To verify the laws, it is convenient to substitute an arbitrary $z^{:Z}$
and define $\tilde{\diamond}_{_{L}}$ and $\tilde{\text{pu}}_{L}$
by
\[
z\triangleright(f\tilde{\diamond}_{_{L}}g)\triangleq(z\triangleright f)\diamond_{_{F}}(z\triangleright g)\quad,\quad\quad z\triangleright\tilde{\text{pu}}_{L}\triangleq\text{pu}_{F}\quad.
\]
For the left-hand side of the associativity law, we write
\[
z\triangleright\big((f\,\tilde{\diamond}_{_{L}}g)\,\tilde{\diamond}_{_{L}}h\big)=\big(z\triangleright(f\,\tilde{\diamond}_{_{L}}g)\big)\diamond_{_{F}}(z\triangleright h)=\big(z\triangleright f)\diamond_{_{F}}(z\triangleright g)\diamond_{_{F}}(z\triangleright h)\quad,
\]
where we omitted parentheses around $\diamond_{_{F}}$ since its associativity
is given. The right-hand side:
\[
z\triangleright\big(f\,\tilde{\diamond}_{_{L}}(g\,\tilde{\diamond}_{_{L}}h\big)=(z\triangleright f)\diamond_{_{F}}\big(z\triangleright(g\,\tilde{\diamond}_{_{L}}h)\big)=\big(z\triangleright f)\diamond_{_{F}}(z\triangleright g)\diamond_{_{F}}(z\triangleright h)\quad.
\]
We obtained the same expression for both sides of the law.

Assuming now that $F$ is a monad with a lawful \lstinline!pure!
method, we verify $L$\textsf{'}s identity laws:
\begin{align*}
{\color{greenunder}\text{left identity law of }L:}\quad & z\triangleright\big(\tilde{\text{pu}}_{L}\tilde{\diamond}_{_{L}}f\big)=(z\triangleright\tilde{\text{pu}}_{L})\diamond_{_{F}}(z\triangleright f)=\gunderline{\text{pu}_{F}\diamond_{_{F}}}(z\triangleright f)=z\triangleright f\quad,\\
{\color{greenunder}\text{right identity law of }L:}\quad & z\triangleright\big(f\,\tilde{\diamond}_{_{L}}\tilde{\text{pu}}_{L}\big)=(z\triangleright f)\diamond_{_{F}}(z\triangleright\tilde{\text{pu}}_{L})=(z\triangleright f)\,\gunderline{\diamond_{_{F}}\text{pu}_{F}}=z\triangleright f\quad.
\end{align*}

It remains to convert the flipped Kleisli methods $\tilde{\diamond}_{_{L}}$
and $\tilde{\text{pu}}_{L}$ to the code of $L$\textsf{'}s \lstinline!flatMap!
and \lstinline!pure!:
\begin{lstlisting}
type L[A] = Z => F[A]           // The type Z and a semimonad F must be already defined.
def flatMap_L[A, B](la: L[A])(f: A => L[B]): L[B] = { z => la(z).flatMap(a => f(a)(z)) }
def pure_L[A](a: A): L[A] = { _ => implicitly[Monad[F]].pure(a) }
\end{lstlisting}


\subsubsection{Statement \label{subsec:Statement-monad-construction-2}\ref{subsec:Statement-monad-construction-2}}

For any contrafunctor $H^{A}$, the functor $L^{A}\triangleq H^{A}\rightarrow A$
is a monad.

\subparagraph{Proof}

We use the flipped Kleisli formulation for $L$. The flipped $L$-Kleisli
functions have types $H^{B}\rightarrow A\rightarrow B$ instead of
$A\rightarrow H^{B}\rightarrow B$. The flipped Kleisli composition
$\tilde{\diamond}_{_{L}}$ of an $f^{:H^{B}\rightarrow A\rightarrow B}$
and a $g^{:H^{C}\rightarrow B\rightarrow C}$ must have type $H^{C}\rightarrow A\rightarrow C$.
To infer this function\textsf{'}s code, begin with a typed hole:
\[
f^{:H^{B}\rightarrow A\rightarrow B}\tilde{\diamond}_{_{L}}g^{:H^{C}\rightarrow B\rightarrow C}=k^{:H^{C}}\rightarrow\text{???}^{:A\rightarrow C}\quad.
\]
Looking at the available data, we notice that a value of type $A\rightarrow C$
will be found if we apply $f$ and $g$ to some arguments and then
compose the resulting functions of types $A\rightarrow B$ and $B\rightarrow C$:
\[
\text{???}^{:A\rightarrow C}=f(\text{???}^{:H^{B}})\bef g(\text{???}^{:H^{C}})\quad.
\]
We already have a value $h$ of type $H^{C}$, so we can apply $g(k)$
and get a function of type $B\rightarrow C$. The remaining typed
hole requires a value of type $H^{B}$; but we only have the value
$k^{:H^{C}}$. We cannot create values of a contrafunctor type $H^{B}$
from scratch. The only way of filling that type hole is to transform
$k$ into the type $H^{B}$. This is possible by lifting a function
of type $B\rightarrow C$ to the contrafunctor $H$, and we already
have such a function, namely $g(k)$. So we write
\[
\text{???}^{:H^{B}}=k^{:H^{C}}\triangleright(\text{???}^{:B\rightarrow C})^{\downarrow H}=k\triangleright(g(k))^{\downarrow H}\quad.
\]
Putting the entire code together and substituting an arbitrary value
$k^{:H^{C}}$, we get
\begin{equation}
k^{:H^{C}}\triangleright\big(f^{:H^{B}\rightarrow A\rightarrow B}\tilde{\diamond}_{_{L}}g^{:H^{C}\rightarrow B\rightarrow C}\big)\triangleq f\big(k\triangleright(g(k))^{\downarrow H}\big)\bef g(k)\quad.\label{eq:def-of-Kleisli-for-exp-construction-h-a-a}
\end{equation}

The flipped \lstinline!pure! method ($\tilde{\text{pu}}_{L}$) is
defined by
\begin{equation}
\tilde{\text{pu}}_{L}^{:H^{A}\rightarrow A\rightarrow A}\triangleq\_^{:H^{A}}\rightarrow\text{id}^{:A\rightarrow A}\quad,\quad\quad\tilde{\text{pu}}_{L}(k)=\text{id}\quad.\label{eq:def-of-pure-for-exp-construction-h-a-a}
\end{equation}
These formulas yield the following Scala definitions of \lstinline!pure!
and \lstinline!flatMap! (see Statement~\ref{subsec:Statement-choice-monad-definition-of-flm}):
\begin{lstlisting}[mathescape=true]
type L[A] = H[A] => A                 // The contrafunctor H must be already defined.
def pure_L[A](a: A): L[A] = { _ => a }
def flatMap_L[B, C](lb: L[B])(g: B => L[C]): L[C] = { (k: H[C]) =>
  val bc: (B => C) = { b => g(b)(k) } // Corresponds to $\color{dkgreen}g(k):B\rightarrow C$.
  val hb: H[B] = k.contramap(bc)     // Fill the typed hole $\color{dkgreen}\textrm{???}:\,\scriptstyle H^B$.
  g(lb(hb))(k)          // Corresponds to the composition $\color{dkgreen} f(...) \bef g(k)$.
}
\end{lstlisting}

Let us now verify the monad laws of $L$ in the flipped Kleisli form.
The identity laws:
\begin{align*}
{\color{greenunder}\text{expect }g(k):}\quad & k\triangleright\big(\tilde{\text{pu}}_{L}\tilde{\diamond}_{_{L}}g\big)=\gunderline{\tilde{\text{pu}}_{L}(k\triangleright(g(k))^{\downarrow H})}\bef g(k)=\gunderline{\text{id}}\bef g(k)=g(k)\quad,\\
{\color{greenunder}\text{expect }f(k):}\quad & k\triangleright\big(f\,\tilde{\diamond}_{_{L}}\tilde{\text{pu}}_{L}\big)=f(k\triangleright(\gunderline{\tilde{\text{pu}}_{L}(k)})^{\downarrow H})\bef\gunderline{\tilde{\text{pu}}_{L}(k)}=f(k\triangleright\gunderline{\text{id}^{\downarrow H}})\bef\gunderline{\text{id}}=f(k)\quad.
\end{align*}

To verify the associativity law, write the two sides separately and
use Eq.~(\ref{eq:def-of-Kleisli-for-exp-construction-h-a-a}) repeatedly:
\begin{align*}
 & k^{:H^{C}}\triangleright\big((f\,\tilde{\diamond}_{_{L}}g)\,\tilde{\diamond}_{_{L}}h\big)=\big(\gunderline{(f\,\tilde{\diamond}_{_{L}}g)(k\triangleright(h(k))^{\downarrow H})}\big)\bef h(k)=\big(\gunderline{k\triangleright(h(k))^{\downarrow H}\triangleright(f\,\tilde{\diamond}_{_{L}}g)}\big)\bef h(k)\\
 & \quad=f\big(k\triangleright(h(k))^{\downarrow H}\triangleright(g(k\triangleright(h(k))^{\downarrow H}))^{\downarrow H}\big)\bef g(k\triangleright(h(k))^{\downarrow H})\bef h(k)\quad,\\
 & k\triangleright\big(f\,\tilde{\diamond}_{_{L}}(g\,\tilde{\diamond}_{_{L}}h)\big)=f\big(k\triangleright(\gunderline{(g\,\tilde{\diamond}_{_{L}}h)(k)})^{\downarrow H}\big)\bef\gunderline{(g\,\tilde{\diamond}_{_{L}}h)(k)}=f\big(k\triangleright(\gunderline{k\triangleright(g\,\tilde{\diamond}_{_{L}}h)})^{\downarrow H}\big)\bef\gunderline{k\triangleright(g\,\tilde{\diamond}_{_{L}}h)}\\
 & \quad=f\big(k\triangleright(\gunderline{g(k\triangleright(h(k))^{\downarrow H})\bef h(k)})^{\downarrow H}\big)\bef g(k\triangleright(h(k))^{\downarrow H})\bef h(k)\\
{\color{greenunder}\text{lift to }H:}\quad & \quad=f\big(k\triangleright(h(k))^{\downarrow H}\triangleright(g(k\triangleright(h(k))^{\downarrow H}))^{\downarrow H}\big)\bef g(k\triangleright(h(k))^{\downarrow H})\bef h(k)\quad.
\end{align*}
Now both sides are rewritten into identical expressions. This confirms
the associativity law for $L$. $\square$

Statement~\ref{subsec:Statement-monad-construction-2} applies to
type constructors of the form $H^{A}\rightarrow A$ but not to $H^{A}\rightarrow G^{A}$
with an arbitrary monad $G$. It turns out that $H^{A}\rightarrow G^{A}$
is a monad when the contrafunctor $H$ is suitably adapted to the
monad $G$. The necessary properties of $H$ are formulated by the
notion of \index{$M$-filterable contrafunctors} $G$-filterable contrafunctor,
which we briefly introduced in Section~\ref{subsec:Motivation-for-using-category-theory}.
We repeat the definition here:

\subsubsection{Definition \label{subsec:Definition-M-filterable-contrafunctor}\ref{subsec:Definition-M-filterable-contrafunctor}}

For a given monad $G$, a contrafunctor $H$ is $G$\textbf{-filterable}
if it has a \lstinline!lift! method,
\[
\text{lift}_{G,H}:(A\rightarrow G^{B})\rightarrow H^{B}\rightarrow H^{A}\quad,
\]
satisfying the identity and (contravariant) composition laws\index{identity laws!of $M$-filterable contrafunctors}\index{composition law!of $M$-filterable contrafunctors}
\[
\text{lift}_{G,H}(\text{pu}_{G})=\text{id}^{:H^{A}\rightarrow H^{A}}\quad,\quad\quad\text{lift}_{G,H}(f\diamond_{_{G}}g)=\text{lift}_{G,H}(g)\bef\text{lift}_{G,H}(f)\quad.
\]

Let us look at some simple examples of $G$-filterable contrafunctors.

\subsubsection{Statement \label{subsec:Statement-examples-of-filterable-contrafunctors}\ref{subsec:Statement-examples-of-filterable-contrafunctors}}

For any given (semi)monad $G$ and any fixed type $Z$, the following
contrafunctors are $G$-filterable: \textbf{(a)} $H^{A}\triangleq Z$,
\textbf{(b)} $H^{A}\triangleq G^{A}\rightarrow Z$, \textbf{(c)} $H^{A}\triangleq A\rightarrow G^{Z}$.

\subparagraph{Proof}

In each case, we need to define the function $\text{lift}_{G,H}$
and verify its laws. If $G$ is only a semimonad, we will derive the
composition law of $\text{lift}_{G,H}$ assuming only the associativity
law of $G$ (but not assuming any identity laws). For a full monad
$G$, we will derive the identity law of $\text{lift}_{G,H}$ by using
the identity laws of $G$. 

\textbf{(a)} Since $H^{A}\triangleq Z$ is a constant contrafunctor,
we define $\text{lift}_{G,H}(f)\triangleq\text{id}^{:Z\rightarrow Z}$.
The identity function will always satisfy the identity and composition
laws.

\textbf{(b)} Define the function $\text{lift}_{G,H}$ by
\begin{lstlisting}
type H[A] = G[A] => Z       // The type Z and the monad G must be already defined.
def lift_G[A, B](k: H[B])(f: A => G[B]): H[A] = { (ga: G[A]) => k(ga.flatMap(f)) }
\end{lstlisting}
\[
\text{lift}_{G,H}(f^{:A\rightarrow G^{B}})\triangleq k^{:G^{B}\rightarrow Z}\rightarrow\text{???}^{:G^{A}\rightarrow Z}=k^{:G^{B}\rightarrow Z}\rightarrow\text{flm}_{G}(f)\bef k\quad,\quad\quad k\triangleright\text{lift}_{G,H}(f)\triangleq\text{flm}_{G}(f)\bef k\quad.
\]
Verify the laws of $\text{lift}_{G,H}$ using the right identity and
the associativity law of $G$\textsf{'}s \lstinline!flatMap!:
\begin{align*}
{\color{greenunder}\text{identity law; expect to equal }k:}\quad & k\triangleright\text{lift}_{G,H}(\text{pu}_{G})=\gunderline{\text{flm}_{G}(\text{pu}_{G})}\bef k=\text{id}\bef k=k\quad,\\
{\color{greenunder}\text{left-hand side of composition law}:}\quad & k\triangleright\text{lift}_{G,H}(f\diamond_{_{G}}g)=\text{flm}_{G}(f\diamond_{_{G}}g)\bef k=\gunderline{\text{flm}_{G}(f\bef\text{flm}_{G}(g))}\bef k\\
{\color{greenunder}\text{associativity law of }\text{flm}_{G}:}\quad & \quad=\text{flm}_{G}(f)\bef\text{flm}_{G}(g)\bef k\quad,\\
{\color{greenunder}\text{right-hand side of composition law}:}\quad & k\triangleright\text{lift}_{G,H}(g)\bef\text{lift}_{G,H}(f)=k\triangleright\text{lift}_{G,H}(g)\,\gunderline{\triangleright\,\text{lift}_{G,H}(f)}\\
 & \quad=\text{flm}_{G}(f)\bef\big(\gunderline{k\triangleright\text{lift}_{G,H}(g)}\big)=\text{flm}_{G}(f)\bef\text{flm}_{G}(g)\bef k\quad.
\end{align*}
Both sides of the composition law of $\text{lift}_{G,H}$ are now
equal.

\textbf{(c)} Define the function $\text{lift}_{G,H}$ by
\begin{lstlisting}
type H[A] = A => G[Z]  // The type Z and the monad G must be already defined.
def lift_G[A, B](k: H[B])(f: A => G[B]): H[A] = { (a: A) => f(a).flatMap(k) }
\end{lstlisting}
\[
\text{lift}_{G,H}(f^{:A\rightarrow G^{B}})\triangleq k^{:B\rightarrow G^{Z}}\rightarrow\text{???}^{:A\rightarrow G^{Z}}=k^{:G^{B}\rightarrow Z}\rightarrow f\diamond_{_{G}}k\quad,\quad\quad k\triangleright\text{lift}_{G,H}(f)\triangleq f\diamond_{_{G}}k\quad.
\]
The laws of $\text{lift}_{G,H}$ are satisfied because the operation
$\diamond_{_{G}}$ obeys its identity and associativity laws:
\begin{align*}
{\color{greenunder}\text{identity law; expect to equal }k:}\quad & k\triangleright\text{lift}_{G,H}(\text{pu}_{G})=\text{pu}_{G}\diamond_{_{G}}k=k\quad,\\
{\color{greenunder}\text{left-hand side of composition law}:}\quad & k\triangleright\text{lift}_{G,H}(f\diamond_{_{G}}g)=(f\diamond_{_{G}}g)\,\diamond_{_{G}}k\quad,\\
{\color{greenunder}\text{right-hand side of composition law}:}\quad & k\triangleright\text{lift}_{G,H}(g)\bef\text{lift}_{G,H}(f)=k\triangleright\text{lift}_{G,H}(g)\,\gunderline{\triangleright\,\text{lift}_{G,H}(f)}\\
 & \quad=f\diamond_{_{G}}\big(\gunderline{k\triangleright\text{lift}_{G,H}(g)}\big)=f\diamond_{_{G}}(g\diamond_{_{G}}k)\quad.
\end{align*}
Both sides of the composition law of $\text{lift}_{G,H}$ are equal
due to the associativity law of $\diamond_{_{G}}$.

$\square$

We will now use filterable contrafunctors to generalize Statements~\ref{subsec:Statement-monad-construction-1}
and~\ref{subsec:Statement-monad-construction-2}.

\subsubsection{Statement \label{subsec:Statement-monad-construction-3}\ref{subsec:Statement-monad-construction-3}}

For any (semi)monad $G$ and any $G$-filterable contrafunctor $H$,
the functor $L$ defined by $L^{A}\triangleq H^{A}\rightarrow G^{A}$
is a (semi)monad.

\subparagraph{Proof}

We use the flipped Kleisli formulation for $L$ and the ordinary Kleisli
formulation for $G$. The flipped $L$-Kleisli functions have types
$H^{B}\rightarrow A\rightarrow G^{B}$ instead of $A\rightarrow H^{B}\rightarrow G^{B}$.
The flipped Kleisli composition $\tilde{\diamond}_{_{L}}$ of an $f^{:H^{B}\rightarrow A\rightarrow G^{B}}$
and a $g^{:H^{C}\rightarrow B\rightarrow G^{C}}$ must have type $H^{C}\rightarrow A\rightarrow G^{C}$.
Similarly to what we did in the proof of Statement~\ref{subsec:Statement-monad-construction-2},
we will define $\tilde{\diamond}_{_{L}}$ by applying $f$ and $g$
to typed holes, getting values of types $A\rightarrow G^{B}$ and
$B\rightarrow G^{C}$, and using the given operation $\diamond_{_{G}}$:
\[
f^{:H^{B}\rightarrow A\rightarrow G^{B}}\tilde{\diamond}_{_{L}}g^{:H^{C}\rightarrow B\rightarrow G^{C}}=k^{:H^{C}}\rightarrow\text{???}^{:A\rightarrow G^{C}}=k^{:H^{C}}\rightarrow f(\text{???}^{:H^{B}})\diamond_{_{G}}g(\text{???}^{:H^{C}})\quad.
\]
The typed hole $\text{???}^{:H^{C}}$ is filled by $k$, while $\text{???}^{:H^{B}}$
is computed from $k$ using $\text{lift}_{G,H}$:
\[
\text{???}^{:H^{B}}=k\triangleright\text{lift}_{G,H}(\text{???}^{:B\rightarrow G^{C}})=k\triangleright\text{lift}_{G,H}(g(k))\quad.
\]
Putting the code together, we obtain
\begin{align*}
 & k^{:H^{C}}\triangleright\big(f^{:H^{B}\rightarrow A\rightarrow G^{B}}\tilde{\diamond}_{_{L}}g^{:H^{C}\rightarrow B\rightarrow G^{C}}\big)\triangleq f\big(k\triangleright\text{lift}_{G,H}(g(k))\big)\diamond_{_{G}}g(k)\quad,\\
 & k^{:H^{C}}\triangleright\tilde{\text{pu}}_{L}\triangleq\text{pu}_{G}\quad.
\end{align*}
These definitions reduce to Eqs.~(\ref{eq:def-of-Kleisli-for-exp-construction-h-a-a})\textendash (\ref{eq:def-of-pure-for-exp-construction-h-a-a})
if we set $G$ to the identity monad, $G^{A}=\text{Id}^{A}\triangleq A$
. Any contrafunctor $H$ is $\text{Id}$-filterable because we can
define the required method $\text{lift}_{\text{Id},H}$ by
\[
\text{lift}_{\text{Id},H}(f^{:B\rightarrow C})\triangleq f^{\downarrow H}\quad.
\]
The laws of $\text{lift}_{\text{Id},H}$ follow from the identity
and composition laws of the contrafunctor $H$.

Translating the monad $L$\textsf{'}s Kleisli composition into Scala code for
\lstinline!flatMap!, we obtain:
\begin{lstlisting}[mathescape=true]
type L[A] = H[A] => G[A] // A contrafunctor H and a monad G must be already defined.
def flatMap_L[A, B](la: L[A])(g: A => L[B]): L[B] = { (k: H[B]) =>
  val agb: (A => G[B]) = { a => g(a)(k) }    // Corresponds to flipped $\color{dkgreen}g(k)$.
  val ha: H[A] = lift_G(k)(agb)    // Corresponds to $\color{dkgreen}k\triangleright  \textrm{lift}_{G,H}(g(k))$.
  la(ha).flatMap(agb)    // Corresponds to the Kleisli composition $\color{dkgreen} f(...) \diamond_{_G}g(k)$.
}
\end{lstlisting}

We now verify the laws via derivations similar to those in the proof
of Statement~\ref{subsec:Statement-monad-construction-2}.

We will need to use the laws of $\text{lift}_{G,H}$ (we will write
simply \textsf{``}$\text{lift}$\textsf{''} for brevity). The identity laws of $L$
follow from the identity laws of $\text{lift}_{G,H}$ and $G$:
\begin{align*}
{\color{greenunder}\text{expect }g(k):}\quad & k\triangleright\big(\tilde{\text{pu}}_{L}\tilde{\diamond}_{_{L}}g\big)=\gunderline{\tilde{\text{pu}}_{L}(k\triangleright\text{lift}\,(g(k)))}\diamond_{_{G}}g(k)=\text{pu}_{G}\diamond_{_{G}}g(k)=g(k)\quad,\\
{\color{greenunder}\text{expect }f(k):}\quad & k\triangleright\big(f\,\tilde{\diamond}_{_{L}}\tilde{\text{pu}}_{L}\big)=f\big(k\triangleright\gunderline{\text{lift}\,(\tilde{\text{pu}}_{L}(k))}\big)\bef\gunderline{\tilde{\text{pu}}_{L}(k)}=f(k\triangleright\gunderline{\text{id}})\diamond_{_{G}}\text{pu}_{G}=f(k)\quad.
\end{align*}

The associativity law of $L$ follows from the associativity of $\diamond_{_{G}}$
and the composition law of $\text{lift}_{G,H}$:
\begin{align*}
 & k^{:H^{C}}\triangleright\big((f\,\tilde{\diamond}_{_{L}}g)\,\tilde{\diamond}_{_{L}}h\big)=\big(\gunderline{(f\tilde{\diamond}_{_{L}}g)(k\triangleright\text{lift}\,(h(k)))}\big)\diamond_{_{G}}h(k)=\big(\gunderline{k\triangleright\text{lift}\,(h(k))\triangleright(f\,\tilde{\diamond}_{_{L}}g)}\big)\diamond_{_{G}}h(k)\\
 & \quad=f\big(k\triangleright\text{lift}\,(h(k))\triangleright\text{lift}\,(g(k\triangleright\text{lift}\,(h(k))))\big)\diamond_{_{G}}g\big(k\triangleright\text{lift}\,(h(k))\big)\diamond_{_{G}}h(k)\quad,\\
 & k\triangleright\big(f\,\tilde{\diamond}_{_{L}}(g\,\tilde{\diamond}_{_{L}}h)\big)=f\big(k\triangleright\text{lift}\,(\gunderline{(g\,\tilde{\diamond}_{_{L}}h)(k)})\big)\diamond_{_{G}}\gunderline{(g\,\tilde{\diamond}_{_{L}}h)(k)}=f\big(k\triangleright\text{lift}\,(\gunderline{k\triangleright(g\,\tilde{\diamond}_{_{L}}h)})\big)\diamond_{_{G}}\gunderline{k\triangleright(g\,\tilde{\diamond}_{_{L}}h)}\\
 & \quad=f\big(k\triangleright\text{lift}\,(\gunderline{g(k\triangleright\text{lift}\,(h(k)))\diamond_{_{G}}h(k)})\big)\diamond_{_{G}}g(k\triangleright\text{lift}\,(h(k)))\diamond_{_{G}}h(k)\\
 & \quad=f\big(k\triangleright\text{lift}\,(h(k))\bef\text{lift}\,(g(k\triangleright\text{lift}\,(h(k))))\big)\diamond_{_{G}}g\big(k\triangleright\text{lift}\,(h(k))\big)\diamond_{_{G}}h(k)\quad.
\end{align*}
Both sides of the associativity law are now converted into identical
expressions. $\square$

Some examples of monads obtained with these constructions for $G^{A}\triangleq\bbnum 1+A$
are
\[
\text{Sel}^{Z,A}\triangleq\left(A\rightarrow Z\right)\rightarrow A\quad,\quad\quad\text{Search}^{Z,A}\triangleq\left(A\rightarrow\bbnum 1+Z\right)\rightarrow\bbnum 1+A\quad,\quad\quad L^{A}\triangleq\left(\bbnum 1+A\rightarrow Z\right)\rightarrow\bbnum 1+A\quad.
\]
The first two of these monads are the selector monad\index{monads!Sel (selector) monad@\texttt{Sel} (selector) monad}
and the \index{monads!Search monad@\texttt{Search} monad}search monad.\footnote{See \texttt{\href{http://math.andrej.com/2008/11/21/a-haskell-monad-for-infinite-search-in-finite-time/}{http://math.andrej.com/2008/11/21/a-haskell-monad-for-infinite-search-in-finite-time/}}}
Statement~\ref{subsec:Statement-monad-construction-3} shows how
to implement the monad methods for these monads and guarantees that
the laws hold.

\paragraph{Recursive types}

The tree-like monads can be generalized to arbitrary shape of leaves
and branches. This gives two constructions that define a monad and
a semimonad from an arbitrary functor.

\subsubsection{Statement \label{subsec:Statement-monad-construction-4}\ref{subsec:Statement-monad-construction-4}}

For any given functor $F$, the recursively defined functor $L^{A}\triangleq A+F^{L^{A}}$
is a (tree-like) monad. The functor $L$ is known as the \textbf{free
monad}\index{free monad}\textbf{ on} $F$, for reasons explained
in Chapter~\ref{chap:Free-type-constructions}.

\subparagraph{Proof}

Begin by implementing the monad methods for $L$ as usual for a tree-like
monad:
\begin{lstlisting}
type L[A] = Either[A, F[L[A]]] // The functor F must be already defined.
def pure_L[A](a: A): L[A] = Left(a)
def flatMap_L[A, B](la: L[A])(f: A => L[B]): L[B] = la match {
  case Left(a)    => f(a)
  case Right(fla) => Right(fla.map { (x: L[A]) => flatMap_L(x)(f) })  // Recursive call of flatMap_L. 
}
def flatten_L[A]: L[L[A]] => L[A] = {   // Match on L[L[A]] = Either[Either[A, F[L[A]]], F[L[L[A]]]].
  case Left(a)              => Left(a)
  case Left(Right(fla))     => Right(fla)
  case Right(Right(flla))   => Right(flla.map(x => flatten_L(x)))     // Recursive call of flatten_L.
}
\end{lstlisting}
\[
\text{pu}_{L}\triangleq\,\begin{array}{|c||cc|}
 & A & F^{L^{A}}\\
\hline A & \text{id} & \bbnum 0
\end{array}\quad,\quad\quad\text{ftn}_{L}^{A}:L^{L^{A}}\rightarrow L^{A}\triangleq\,\begin{array}{|c||cc|}
 & A & F^{L^{A}}\\
\hline A & \text{id} & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \text{id}\\
F^{L^{L^{A}}} & \bbnum 0 & \overline{\text{ftn}}_{L}^{\uparrow F}
\end{array}\quad.
\]

To verify the monad laws for $L$, we need to lift $\text{pu}_{L}$
and $\text{ftn}_{L}$ to the functor $L$. The lifting code is
\[
(f^{:A\rightarrow B})^{\uparrow L}=\,\begin{array}{|c||cc|}
 & B & F^{L^{B}}\\
\hline A & f & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \big(f^{\overline{\uparrow L}}\big)^{\uparrow F}
\end{array}\quad.
\]
In order to compute function compositions such as $\text{pu}_{L}^{\uparrow L}\bef\text{ftn}_{L}$
and $\text{ftn}_{L}^{\uparrow L}\bef\text{ftn}$ in the matrix notation,
we need to expand the matrices of $\text{pu}_{L}$ and $\text{ftn}_{L}$,
so that their output types are fully split:
\[
\text{pu}_{L}^{\uparrow L}=\,\begin{array}{|c||cc|}
 & L^{A} & F^{L^{L^{A}}}\\
\hline A & \text{pu}_{L} & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \big(\text{pu}_{L}^{\overline{\uparrow L}}\big)^{\uparrow F}
\end{array}\,=\,\begin{array}{|c||ccc|}
 & A & F^{L^{A}} & F^{L^{L^{A}}}\\
\hline A & \text{id} & \bbnum 0 & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \bbnum 0 & \big(\text{pu}_{L}^{\overline{\uparrow L}}\big)^{\uparrow F}
\end{array}\quad,
\]
\[
\text{ftn}_{L}^{\uparrow L}=\,\begin{array}{|c||cc|}
 & L^{A} & F^{L^{L^{A}}}\\
\hline L^{L^{A}} & \text{ftn}_{L} & \bbnum 0\\
F^{L^{L^{L^{A}}}} & \bbnum 0 & \big(\text{ftn}_{L}^{\overline{\uparrow L}}\big)^{\uparrow F}
\end{array}\,=\,\begin{array}{|c||ccc|}
 & A & F^{L^{A}} & F^{L^{L^{A}}}\\
\hline A & \text{id} & \bbnum 0 & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \text{id} & \bbnum 0\\
F^{L^{L^{A}}} & \bbnum 0 & \overline{\text{ftn}}_{L}^{\uparrow F} & \bbnum 0\\
F^{L^{L^{L^{A}}}} & \bbnum 0 & \bbnum 0 & \big(\text{ftn}_{L}^{\overline{\uparrow L}}\big)^{\uparrow F}
\end{array}\quad.
\]
We can now verify the identity and associativity laws of $\text{pu}_{L}$
and $\text{ftn}_{L}$. Identity laws:
\[
\text{pu}_{L}^{L^{A}}\bef\text{ftn}_{L}=\,\begin{array}{|c||ccc|}
 & A & F^{L^{A}} & F^{L^{L^{A}}}\\
\hline A & \text{id} & \bbnum 0 & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \text{id} & \bbnum 0
\end{array}\,\bef\,\begin{array}{|c||cc|}
 & A & F^{L^{A}}\\
\hline A & \text{id} & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \text{id}\\
F^{L^{L^{A}}} & \bbnum 0 & \overline{\text{ftn}}_{L}^{\uparrow F}
\end{array}\,=\,\begin{array}{|c||cc|}
 & A & F^{L^{A}}\\
\hline A & \text{id} & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \text{id}
\end{array}\,=\text{id}\quad,
\]
\[
\text{pu}_{L}^{\uparrow L}\bef\text{ftn}_{L}=\,\begin{array}{|c||ccc|}
 & A & F^{L^{A}} & F^{L^{L^{A}}}\\
\hline A & \text{id} & \bbnum 0 & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \bbnum 0 & \big(\text{pu}_{L}^{\overline{\uparrow L}}\big)^{\uparrow F}
\end{array}\,\bef\,\begin{array}{|c||cc|}
 & A & F^{L^{A}}\\
\hline A & \text{id} & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \text{id}\\
F^{L^{L^{A}}} & \bbnum 0 & \overline{\text{ftn}}_{L}^{\uparrow F}
\end{array}
\]
\[
\quad=\,\begin{array}{|c||cc|}
 & A & F^{L^{A}}\\
\hline A & \text{id} & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \gunderline{\big(\text{pu}_{L}^{\overline{\uparrow L}}\big)^{\uparrow F}\bef\overline{\text{ftn}}_{L}^{\uparrow F}}
\end{array}\,=\,\begin{array}{|c||cc|}
 & A & F^{L^{A}}\\
\hline A & \text{id} & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \text{id}
\end{array}\,=\text{id}\quad,
\]
where in the last line we used the inductive assumption $\big(\text{pu}_{L}^{\overline{\uparrow L}}\big)^{\uparrow F}\bef\overline{\text{ftn}}_{L}^{\uparrow F}=\text{id}$.

To verify the associativity law, simplify its both sides separately
and use fully split matrices:
\[
\text{ftn}_{L}^{L^{A}}\bef\text{ftn}_{L}=\,\begin{array}{|c||ccc|}
 & A & F^{L^{A}} & F^{L^{L^{A}}}\\
\hline A & \text{id} & \bbnum 0 & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \text{id} & \bbnum 0\\
F^{L^{L^{A}}} & \bbnum 0 & \bbnum 0 & \text{id}\\
F^{L^{L^{L^{A}}}} & \bbnum 0 & \bbnum 0 & \overline{\text{ftn}}_{L}^{\uparrow F}
\end{array}\,\bef\,\begin{array}{|c||cc|}
 & A & F^{L^{A}}\\
\hline A & \text{id} & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \text{id}\\
F^{L^{L^{A}}} & \bbnum 0 & \overline{\text{ftn}}_{L}^{\uparrow F}
\end{array}\,=\,\begin{array}{|c||cc|}
 & A & F^{L^{A}}\\
\hline A & \text{id} & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \text{id}\\
F^{L^{L^{A}}} & \bbnum 0 & \overline{\text{ftn}}_{L}^{\uparrow F}\\
F^{L^{L^{L^{A}}}} & \bbnum 0 & \overline{\text{ftn}}_{L}^{\uparrow F}\bef\overline{\text{ftn}}_{L}^{\uparrow F}
\end{array}\quad,
\]
\[
\negthickspace\negthickspace\negthickspace\negthickspace\text{ftn}_{L}^{\uparrow L}\bef\text{ftn}_{L}=\,\begin{array}{|c||ccc|}
 & A & F^{L^{A}} & F^{L^{L^{A}}}\\
\hline A & \text{id} & \bbnum 0 & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \text{id} & \bbnum 0\\
F^{L^{L^{A}}} & \bbnum 0 & \overline{\text{ftn}}_{L}^{\uparrow F} & \bbnum 0\\
F^{L^{L^{L^{A}}}} & \bbnum 0 & \bbnum 0 & \big(\text{ftn}_{L}^{\overline{\uparrow L}}\big)^{\uparrow F}
\end{array}\,\bef\,\begin{array}{|c||cc|}
 & A & F^{L^{A}}\\
\hline A & \text{id} & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \text{id}\\
F^{L^{L^{A}}} & \bbnum 0 & \overline{\text{ftn}}_{L}^{\uparrow F}
\end{array}\,=\,\begin{array}{|c||cc|}
 & A & F^{L^{A}}\\
\hline A & \text{id} & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \text{id}\\
F^{L^{L^{A}}} & \bbnum 0 & \overline{\text{ftn}}_{L}^{\uparrow F}\\
F^{L^{L^{L^{A}}}} & \bbnum 0 & \big(\text{ftn}_{L}^{\overline{\uparrow L}}\big)^{\uparrow F}\bef\overline{\text{ftn}}_{L}^{\uparrow F}
\end{array}\quad.
\]
The two resulting matrices are equal due to the inductive assumption,
\[
\overline{\text{ftn}}_{L}\bef\overline{\text{ftn}}_{L}=\text{ftn}_{L}^{\overline{\uparrow L}}\bef\overline{\text{ftn}}_{L}\quad.
\]


\subsubsection{Statement \label{subsec:Statement-monad-construction-5}\ref{subsec:Statement-monad-construction-5}}

For any functor $F$, the recursive functor $L^{A}\triangleq F^{A}+F^{L^{A}}$
(representing a tree with $F$-shaped leaves and branches) is a semimonad
but not a monad.

\subparagraph{Proof}

We have already implemented the \lstinline!flatMap! method for an
equivalent functor in Section~\ref{subsec:Tree-like-semimonads-and-monads}.
The corresponding \lstinline!flatten! method is
\begin{lstlisting}
type L[A] = Either[F[A], F[L[A]]]     // The functor F must be already defined.
def flatten_L[A]: L[L[A]] => L[A] = { // Match on L[L[A]] = Either[F[L[A]], F[L[L[A]]]].
  case Left(fla)     => Right(fla)
  case Right(flla)   => Right(flla.map(x => flatten_L(x)))
}
\end{lstlisting}
Prepare the code of \lstinline!flatten! and its lifting to $L$ in
the matrix notation:
\[
\text{ftn}_{L}^{A}=\,\begin{array}{|c||cc|}
 & F^{A} & F^{L^{A}}\\
\hline F^{L^{A}} & \bbnum 0 & \text{id}\\
F^{L^{L^{A}}} & \bbnum 0 & \overline{\text{ftn}_{L}}^{\uparrow F}
\end{array}\quad,\quad\quad\text{ftn}_{L}^{L^{A}}=\,\begin{array}{|c||cc|}
 & F^{L^{A}} & F^{L^{L^{A}}}\\
\hline F^{L^{L^{A}}} & \bbnum 0 & \text{id}\\
F^{L^{L^{L^{A}}}} & \bbnum 0 & \overline{\text{ftn}_{L}}^{\uparrow F}
\end{array}\quad,
\]
\[
(f^{:A\rightarrow B})^{\uparrow L}=\,\begin{array}{|c||cc|}
 & F^{B} & F^{L^{B}}\\
\hline F^{A} & f^{\uparrow F} & \bbnum 0\\
F^{L^{A}} & \bbnum 0 & \big(f^{\overline{\uparrow L}}\big)^{\uparrow F}
\end{array}\quad,\quad\quad\text{ftn}_{L}^{\uparrow L}=\,\begin{array}{|c||cc|}
 & F^{L^{A}} & F^{L^{L^{A}}}\\
\hline F^{L^{L^{A}}} & \overline{\text{ftn}_{L}}^{\uparrow F} & \bbnum 0\\
F^{L^{L^{L^{A}}}} & \bbnum 0 & \big(\text{ftn}_{L}^{\overline{\uparrow L}}\big)^{\uparrow F}
\end{array}\quad.
\]
To verify the associativity law, write both its parts separately:
\[
\text{ftn}_{L}^{L^{A}}\bef\text{ftn}_{L}=\,\begin{array}{|c||cc|}
 & F^{L^{A}} & F^{L^{L^{A}}}\\
\hline F^{L^{L^{A}}} & \bbnum 0 & \text{id}\\
F^{L^{L^{L^{A}}}} & \bbnum 0 & \overline{\text{ftn}_{L}}^{\uparrow F}
\end{array}\,\bef\,\begin{array}{|c||cc|}
 & F^{A} & F^{L^{A}}\\
\hline F^{L^{A}} & \bbnum 0 & \text{id}\\
F^{L^{L^{A}}} & \bbnum 0 & \overline{\text{ftn}_{L}}^{\uparrow F}
\end{array}\,=\,\begin{array}{|c||cc|}
 & F^{A} & F^{L^{A}}\\
\hline F^{L^{L^{A}}} & \bbnum 0 & \overline{\text{ftn}}^{\uparrow F}\\
F^{L^{L^{L^{A}}}} & \bbnum 0 & \overline{\text{ftn}_{L}}^{\uparrow F}\bef\overline{\text{ftn}_{L}}^{\uparrow F}
\end{array}\quad,
\]
\[
\negthickspace\negthickspace\negthickspace\negthickspace\text{ftn}_{L}^{\uparrow L}\bef\text{ftn}_{L}=\,\begin{array}{|c||cc|}
 & F^{L^{A}} & F^{L^{L^{A}}}\\
\hline F^{L^{L^{A}}} & \overline{\text{ftn}_{L}}^{\uparrow F} & \bbnum 0\\
F^{L^{L^{L^{A}}}} & \bbnum 0 & \big(\text{ftn}_{L}^{\overline{\uparrow L}}\big)^{\uparrow F}
\end{array}\,\bef\,\begin{array}{|c||cc|}
 & F^{A} & F^{L^{A}}\\
\hline F^{L^{A}} & \bbnum 0 & \text{id}\\
F^{L^{L^{A}}} & \bbnum 0 & \overline{\text{ftn}_{L}}^{\uparrow F}
\end{array}\,=\,\begin{array}{|c||cc|}
 & F^{A} & F^{L^{A}}\\
\hline F^{L^{L^{A}}} & \bbnum 0 & \overline{\text{ftn}_{L}}^{\uparrow F}\\
F^{L^{L^{L^{A}}}} & \bbnum 0 & \big(\text{ftn}_{L}^{\overline{\uparrow L}}\big)^{\uparrow F}\bef\overline{\text{ftn}_{L}}^{\uparrow F}
\end{array}\quad.
\]
The two resulting matrices are equal due to the inductive assumption,
\[
\overline{\text{ftn}}_{L}^{\uparrow F}\bef\overline{\text{ftn}}_{L}^{\uparrow F}=\big(\text{ftn}_{L}^{\overline{\uparrow L}}\big)^{\uparrow F}\bef\overline{\text{ftn}}_{L}^{\uparrow F}\quad.
\]

Could $L$ be a full monad? Suppose we were given some code for the
\lstinline!pure! method ($\text{pu}_{L}$). If we substitute an arbitrary
value $k^{:L^{A}}$ into the left identity law, we expect to obtain
again $k$:
\[
k^{:L^{A}}\triangleright\text{pu}_{L}\bef\text{ftn}_{L}=k\triangleright\text{pu}_{L}\triangleright\,\begin{array}{|c||cc|}
 & F^{A} & F^{L^{A}}\\
\hline F^{L^{A}} & \bbnum 0 & \text{id}\\
F^{L^{L^{A}}} & \bbnum 0 & \overline{\text{ftn}_{L}}^{\uparrow F}
\end{array}\,\overset{?}{=}k\quad.
\]
We notice that the matrix for $\text{ftn}_{L}$ has no elements in
the $F^{A}$ column. This suggests information loss: the value $k\triangleright\text{pu}_{L}\bef\text{ftn}_{L}$
will be always of the form $\bbnum 0+q^{:F^{L^{A}}}$ with some $q$,
regardless of $k$ and of the implementation of $\text{pu}_{L}$.
So, if we set $k\triangleq p^{:F^{A}}+\bbnum 0$ with some $p$, the
law cannot  hold. The same problem occurs with the right identity
law. We conclude that $L$ cannot be a full monad.

\subsection{Exercises: laws and structure of monads\index{exercises}}

\subsubsection{Exercise \label{subsec:Exercise-semimonad-not-monad}\ref{subsec:Exercise-semimonad-not-monad}}

For fixed types $U$ and $V$, define \lstinline!flatten! for the
semimonad $F^{A}\triangleq A\times U\times V$ as
\[
\text{ftn}_{F}\triangleq(a^{:A}\times u_{1}^{:U}\times v_{1}^{:V})\times u_{2}^{:U}\times v_{2}^{:V}\rightarrow a\times u_{1}\times v_{2}\quad.
\]
A \lstinline!pure! method could be defined for $F$ if some fixed
values $u_{0}^{:U}$ and $v_{0}^{:V}$ were given:
\[
\text{pu}_{F}\triangleq a^{:A}\rightarrow a\times u_{0}\times v_{0}\quad.
\]
Show that $F$ would still not be a full monad because identity laws
fail to hold.

\subsubsection{Exercise \label{subsec:Exercise-1-monads-2}\ref{subsec:Exercise-1-monads-2}}

Suppose a monad $M$ is defined using the \lstinline!pure! and \lstinline!flatten!
methods that satisfy all laws, in particular, the left identity law
$\text{pu}_{M}\bef\text{ftn}_{M}=\text{id}$. The \lstinline!flatMap!
function is then defined through \lstinline!flatten! by $\text{flm}_{M}(f)\triangleq f^{\uparrow M}\bef\text{ftn}_{M}$.
Show that this \lstinline!flatMap! function will satisfy its left
identity law ($\text{pu}_{M}\bef\text{flm}_{M}(f)=f$ for any $f^{:A\rightarrow M^{B}}$).

\subsubsection{Exercise \label{subsec:Exercise-1-monads-3}\ref{subsec:Exercise-1-monads-3}}

Verify the associativity law for the \lstinline!Reader! monad by
an explicit derivation.

\subsubsection{Exercise \label{subsec:Exercise-1-monads-4}\ref{subsec:Exercise-1-monads-4}}

Given an arbitrary monad $M$, show that the functor $F^{A}\triangleq\bbnum 2\times M^{A}$
(which is equivalent to $M^{A}+M^{A}$) is a semimonad but not a full
monad.

\subsubsection{Exercise \label{subsec:Exercise-1-monads-9}\ref{subsec:Exercise-1-monads-9}}

Show that $P^{A}\triangleq Z+W\times A$ is a (full) monad if $W$
is a monoid.

\subsubsection{Exercise \label{subsec:Exercise-1-monads-5}\ref{subsec:Exercise-1-monads-5}}

If $W$ and $R$ are arbitrary fixed types, is any of the functors
$F^{A}\triangleq W\times\left(R\rightarrow A\right)$ and $G^{A}\triangleq R\rightarrow\left(W\times A\right)$
a lawful semimonad? Hint: try to define \lstinline!flatten! for these
functors.

\subsubsection{Exercise \label{subsec:Exercise-1-monads-6}\ref{subsec:Exercise-1-monads-6}}

Show that $F^{A}\triangleq\left(P\rightarrow A\right)+\left(Q\rightarrow A\right)$
is not a semimonad (cannot define \lstinline!flatMap!) when $P$
and $Q$ are fixed types that are different and not related by subtyping.

\subsubsection{Exercise \label{subsec:Exercise-1-monads-7}\ref{subsec:Exercise-1-monads-7}{*}}

Consider the functor $D^{A}\triangleq\bbnum 1+A\times A$ (in Scala,
\lstinline!type D[A] = Option[(A, A)]!). Implement the \lstinline!flatten!
and \lstinline!pure! methods for $D$ in two or more different ways,
and show that some of the monad laws fail to hold for each of those
implementations.\footnote{One can prove that $D^{A}\triangleq\bbnum 1+A\times A$ cannot be
a lawful monad; see \href{https://stackoverflow.com/questions/49742377/}{https://stackoverflow.com/questions/49742377/}}

\subsubsection{Exercise \label{subsec:Exercise-1-monads-8}\ref{subsec:Exercise-1-monads-8}}

For the type constructor $F^{A}\triangleq Z\times\left(A\rightarrow Z\right)$,
a programmer defined \lstinline!flatMap! by
\begin{lstlisting}
type F[A] = (Z, A => Z) // The fixed type Z must be already defined.
def flatMap_F[A, B](fa: F[A])(f: A => F[B]): F[B] = fa match { case (z, g) => (z, _ => z) }
\end{lstlisting}
\[
\text{flm}_{F}(f^{:A\rightarrow Z\times\left(B\rightarrow Z\right)})\triangleq z^{:Z}\times g^{:A\rightarrow Z}\rightarrow z\times(\_^{:B}\rightarrow z)\quad.
\]
Show that this implementation fails to satisfy the semimonad laws.
(Here, $Z$ is a fixed type.)

\subsubsection{Exercise \label{subsec:Exercise-flatten-concat-distributive-law}\ref{subsec:Exercise-flatten-concat-distributive-law}{*}}

Prove (by induction on $p$) that \lstinline!flatten! and \lstinline!concat!
satisfy the distributive law\index{distributive law!of concat@of \texttt{concat}}:
\[
\left(p\pplus q\right)\triangleright\text{ftn}=\left(p\triangleright\text{ftn}\right)\pplus\left(q\triangleright\text{ftn}\right)\quad,\quad\quad\forall p:\text{List}^{\text{List}^{A}},\,q:\text{List}^{\text{List}^{A}}\quad.
\]


\subsubsection{Exercise \label{subsec:Exercise-1-monads-9-1-1}\ref{subsec:Exercise-1-monads-9-1-1}}

Given a monad $M$, consider a function \lstinline!toUnit! (denoted
$\text{tu}_{M}$) with type signature

\begin{wrapfigure}{l}{0.61\columnwidth}%
\vspace{-0.5\baselineskip}
\begin{lstlisting}
def toUnit[M[_]: Monad, A]: M[A] => M[Unit] = _.map(_ => ())
\end{lstlisting}

\vspace{-0.5\baselineskip}
\end{wrapfigure}%

~\vspace{-0.9\baselineskip}
\[
\text{tu}_{M}:M^{A}\rightarrow M^{\bbnum 1}\triangleq(\_^{:A}\rightarrow1)^{\uparrow M}\quad.
\]
Show that this function satisfies the equation
\[
\text{pu}_{M}^{:A\rightarrow M^{A}}\bef\text{tu}_{M}^{:M^{A}\rightarrow M^{1}}=\_^{:A}\rightarrow\text{pu}_{M}(1)\quad.
\]


\subsubsection{Exercise \label{subsec:Exercise-monad-of-monoid-is-monoid}\ref{subsec:Exercise-monad-of-monoid-is-monoid}}

Show that \lstinline!M[W]! is a monoid if \lstinline!M[_]! is a
monad and \lstinline!W! is a monoid.

\subsubsection{Exercise \label{subsec:Exercise-1-monads-9-1}\ref{subsec:Exercise-1-monads-9-1}}

A monad is called \textbf{commutative}\index{monads!commutative}
if swapping the order of its effects gives the same results. In terms
of functor block code, this means that \lstinline!result1! and \lstinline!result2!
are equal:

\noindent \texttt{\textcolor{blue}{\footnotesize{}}}%
\begin{minipage}[c]{0.475\columnwidth}%
\texttt{\textcolor{blue}{\footnotesize{}}}
\begin{lstlisting}
result1 = for { // Assume p: M[A],  q: M[B],
    x <- p    // and q does not depend on x.
    y <- q
} yield f(x, y)   // For any f: (A, B) => C.
\end{lstlisting}
%
\end{minipage}\texttt{\textcolor{blue}{\footnotesize{}\hspace*{\fill}}}%
\begin{minipage}[c]{0.475\columnwidth}%
\texttt{\textcolor{blue}{\footnotesize{}}}
\begin{lstlisting}
result2 = for { // Assume p: M[A],  q: M[B],
    y <- q    // and p does not depend on y.
    x <- p
} yield f(x, y)   // For any f: (A, B) => C.
\end{lstlisting}
%
\end{minipage}{\footnotesize\par}

\noindent \vspace{0\baselineskip}

\textbf{(a)} Check whether the \lstinline!Option!, \lstinline!List!,
\lstinline!Reader!, \lstinline!Writer!, and \lstinline!State! monads
are commutative.

\textbf{(b)} Consider the type $M^{\bbnum 1}$ (in Scala, this is
\lstinline!M[Unit]!). Since the \lstinline!Unit! type is a (trivial)
monoid, Exercise~\ref{subsec:Exercise-monad-of-monoid-is-monoid}
shows that $M^{\bbnum 1}$ is also a monoid. Prove that if the monad
$M$ is commutative then the binary operation $\oplus_{M}$ of the
monoid $M^{\bbnum 1}$ is also commutative. 

\subsubsection{Exercise \label{subsec:Exercise-1-monads-11}\ref{subsec:Exercise-1-monads-11}}

Use monad constructions (so that law checking is unnecessary) to implement
\lstinline!flatten! and \lstinline!pure! for $F^{A}\triangleq A+\left(R\rightarrow A\right)$,
where $R$ is a fixed type.

\subsubsection{Exercise \label{subsec:Exercise-1-monads-12}\ref{subsec:Exercise-1-monads-12}}

Consider the alternative way of defining the \lstinline!pure! method
for the monad construction $L^{A}\triangleq A+G^{A}$ (Statement~\ref{subsec:Statement-co-product-with-identity-monad}),
where $G$ is a monad. Show that the identity laws will not hold for
$L$ if \lstinline!pure! is defined as \lstinline!a => Right(Monad[G].pure(a))!
(in the code notation, $\text{pu}_{L}\triangleq a\rightarrow\bbnum 0+a\triangleright\text{pu}_{G}$).

\subsubsection{Exercise \label{subsec:Exercise-1-monads-13}\ref{subsec:Exercise-1-monads-13}}

Implement the functor and monad methods for $F^{A}\triangleq\left(Z\rightarrow\bbnum 1+A\right)\times\text{List}^{A}$
using the known constructions (so that law checking is unnecessary).

\subsubsection{Exercise \label{subsec:Exercise-1-monads-16}\ref{subsec:Exercise-1-monads-16}}

Use monad constructions to show that the functors $F$ defined below
are monads:

\textbf{(a)} $F^{A}\triangleq A+A+...+A$ and $F^{A}\triangleq A\times A\times...\times A$
(with a fixed number of $A$\textsf{'}s).

\textbf{(b)} A polynomial functor $F^{A}\triangleq p(A)$ when $p(x)$
is a polynomial of the form $p(x)=x^{n_{1}}+x^{n_{2}}+...+x^{n_{k}}$
for some positive integers $n_{1}$, ..., $n_{k}$; for example, $F^{A}\triangleq A\times A\times A+A\times A\times A\times A\times A+A\times A$. 

\textbf{(c)} A polynomial functor $F^{A}\triangleq p(A)$ when $p(x)$
is a polynomial of the form $p(x)=c_{1}x^{n_{1}}+c_{2}x^{n_{2}}+...+c_{k-1}x^{n_{k-1}}+x^{n_{k}}$
for some positive integers $n_{1}$, ..., $n_{k}$, $c_{1}$, ...,
$c_{k-1}$; for example, $F^{A}\triangleq\bbnum 2\times A+\bbnum 5\times A\times A\times A+A\times A\times A\times A$.
(The coefficient at the highest power of the polynomial \emph{must}
be $1$.)

\subsubsection{Exercise \label{subsec:Exercise-monad-composition-mm}\ref{subsec:Exercise-monad-composition-mm}{*}{*}}

If $M$ is a monad, show that $L^{A}\triangleq M^{M^{A}}$ is a semimonad
but not always a monad.

\section{Further developments}

\subsection{Why monads must be functors}

We defined monads as functors with extra properties. It turns out
that monads cannot be contrafunctors, and that the functor laws of
a monad can be derived from the laws of \lstinline!flatMap!.

A monad\textsf{'}s code can be specified in three equivalent ways: via \lstinline!flatMap!
and \lstinline!pure!, via \lstinline!flatten! and \lstinline!pure!,
or via the Kleisli composition and \lstinline!pure!. These methods
have different laws and different uses. The \lstinline!flatMap! method
is used most frequently, while the Kleisli composition is rarely used.
Since
\[
\text{flm}_{M}(f)=f^{\uparrow M}\bef\text{ftn}_{M}\quad,
\]
we could imagine that \lstinline!flatMap! already has the capability
of lifting a function ($f^{\uparrow M}$). Let us extract that capability
from the code of \lstinline!flatMap!: compose $f^{\uparrow M}$ with
the right identity law,
\[
\text{pu}_{M}^{\uparrow M}\bef\text{ftn}_{M}=\text{id}\quad,\quad\text{ so }\quad f^{\uparrow M}\bef\gunderline{\text{pu}_{M}^{\uparrow M}\bef\text{ftn}_{M}}=f^{\uparrow M}\quad.
\]
The left-hand side equals $\text{flm}_{M}(f\bef\text{pu}_{M})$. We
found a formula that expresses \lstinline!map! through \lstinline!flatMap!:

\begin{wrapfigure}{l}{0.5\columnwidth}%
\vspace{-0.5\baselineskip}
\begin{lstlisting}
p.map(f) == p.flatMap(f andThen M.pure)
\end{lstlisting}

\vspace{-0.5\baselineskip}
\end{wrapfigure}%

~\vspace{-0.1\baselineskip}
\[
f^{\uparrow M}=\text{flm}_{M}(f\bef\text{pu}_{M})\quad.
\]

The laws of \lstinline!map! will then follow if we assume that \lstinline!flatMap!
is lawful. The identity law of \lstinline!map!:
\begin{align*}
 & \text{id}^{\uparrow M}=\text{flm}_{M}(\text{id}\bef\text{pu}_{M})=\gunderline{\text{flm}_{M}(\text{pu}_{M})}\\
{\color{greenunder}\text{right identity law of }\text{flm}_{M}:}\quad & =\text{id}\quad.
\end{align*}
The composition law of \lstinline!map!:
\begin{align*}
{\color{greenunder}\text{expect to equal }(f\bef g)^{\uparrow M}:}\quad & f^{\uparrow M}\bef g^{\uparrow M}=\text{flm}_{M}(f\bef\text{pu}_{M})\bef\text{flm}_{M}(g\bef\text{pu}_{M})\\
{\color{greenunder}\text{associativity law of }\text{flm}_{M}:}\quad & =\text{flm}_{M}(f\bef\gunderline{\text{pu}_{M}\bef\text{flm}_{M}}(g\bef\text{pu}_{M}))\\
{\color{greenunder}\text{left identity law of }\text{flm}_{M}:}\quad & =\text{flm}_{M}(f\bef g\bef\text{pu}_{M})=(f\bef g)^{\uparrow M}\quad.
\end{align*}

If a monad $M$ is specified via its Kleisli composition $\diamond_{_{M}}$,
we can first define \lstinline!flatMap! by
\[
\text{flm}_{M}(f^{:A\rightarrow M^{B}})\triangleq\text{id}^{:M^{A}\rightarrow M^{A}}\diamond_{_{M}}f\quad,
\]
and then derive \lstinline!map! from \lstinline!flatMap! as before.

If a monad\textsf{'}s code is defined via \lstinline!pure! and \lstinline!flatten!,
we cannot derive the \lstinline!map! method. So, we could indeed
say heuristically that \lstinline!flatten! has the functionality
of \lstinline!flatMap! without \lstinline!map!.

In the previous chapter, we have seen that the laws of filterable
functors are straightforwardly adapted to filterable contrafunctors.
Could we do that with monads to obtain \textsf{``}contramonads\textsf{''}? It turns
out that nontrivial \textsf{``}contramonads\index{contramonads}\textsf{''} do not
exist. 

The first problem is defining a method analogous to \lstinline!flatMap!
for contrafunctors. We turn to category theory (Section~\ref{subsec:Motivation-for-using-category-theory})
for guidance. The type signature of a monad\textsf{'}s \lstinline!flatMap!
is that of a lifting,
\[
\text{flm}_{M}:(A\rightarrow M^{B})\rightarrow M^{A}\rightarrow M^{B}\quad,
\]
corresponding to a functor from the $M$-Kleisli category to the $M$-lifted
category. To adapt this construction to a contrafunctor $H^{A}$,
we need to define a lifting called, say, \textsf{``}\lstinline!contraFlatMap!\textsf{''},
with the type 
\[
\text{cflm}_{H}:(A\rightarrow H^{B})\rightarrow H^{B}\rightarrow H^{A}\quad.
\]
We notice a curious feature of this type signature: since $H^{B}$
is contravariant in $B$, the entire type of $\text{cflm}_{H}$ is
contravariant in $B$. So, $\text{cflm}_{H}$ does not have the type
of a natural transformation with respect to $B$, unlike all other
liftings we have seen, such as \lstinline!map!, \lstinline!liftOpt!,
and \lstinline!flatMap!. If the code of $\text{cflm}_{H}$ is fully
parametric then $\text{cflm}_{H}$ must satisfy a corresponding naturality
law. It turns out that the naturality law gives a constraint so strong
that it forces $H$ to be a \emph{constant} contrafunctor.

To see that, consider the left naturality law of $\text{cflm}_{H}$
(with respect to the type parameter $A$):
\begin{equation}
\text{cflm}_{H}(f^{:A\rightarrow B}\bef g^{:B\rightarrow H^{C}})=\text{cflm}_{H}(g)\bef f^{\downarrow H}\quad.\label{eq:contramonad-left-naturality-law}
\end{equation}
If $H$ were a \textsf{``}contramonad\textsf{''}, it would have a method analogous
to \lstinline!pure! with type signature $A\rightarrow H^{A}$ satisfying
the right identity law
\[
\text{cflm}_{H}(\text{pu}_{H})=\text{id}\quad.
\]
Substitute $g=\text{pu}_{H}$ into Eq.~(\ref{eq:contramonad-left-naturality-law})
and obtain
\begin{equation}
\text{cflm}_{H}(f\bef\text{pu}_{H})=\text{id}\bef f^{\downarrow H}=f^{\downarrow H}\quad.\label{eq:contramonad-naturality-derivation1}
\end{equation}
The method \lstinline!pure! for a contrafunctor $H$ is equivalent
to a value $\text{wu}_{H}$ of type $H^{\bbnum 1}$ (Section~\ref{subsec:Pointed-contrafunctors}).
In other words, the naturality law for $\text{pu}_{H}:A\rightarrow H^{A}$
forces it to be a function that ignores its argument and always returns
a fixed value of type $H^{A}$, denoted by $\text{cpu}_{H}$ in Sections~\ref{subsec:Co-pointed-functors}\textendash \ref{subsec:Pointed-contrafunctors}:
\[
\text{pu}_{H}=\_^{:A}\rightarrow\text{cpu}_{H}^{A}=\_^{:A}\rightarrow\text{wu}_{H}\triangleright(\_^{:A}\rightarrow1)^{\downarrow H}\quad.
\]
Since $\text{pu}_{H}$ ignores its argument, we have $f\bef\text{pu}_{H}=\text{pu}_{H}$
for any function $f$. Then Eq.~(\ref{eq:contramonad-naturality-derivation1})
gives
\[
f^{\downarrow H}=\text{cflm}_{H}(f\bef\text{pu}_{H})=\text{cflm}_{H}(\text{pu}_{H})=\text{id}\quad.
\]
The equation $f^{\downarrow H}=\text{id}$ holds only for constant
contrafunctors $H^{A}\triangleq Z$ (with some fixed type $Z$). Constant
contrafunctors are functors at the same time. We know from Section~\ref{subsec:Structural-analysis-of-monads}
that constant functors $F^{A}=Z$ are monads only when $Z=\bbnum 1$.
So, nontrivial \textsf{``}contramonads\textsf{''} are not possible. 

\subsection{Equivalence of a natural transformation and a \textsf{``}lifting\textsf{''}}

In this and the previous chapters, we have derived the laws for three
typeclasses: filterable functors, filterable contrafunctors, and monads.
In each case, the laws were formulated in terms of lifting-like functions
(\lstinline!liftOpt!, \lstinline!flatMap!), with type signatures:
\begin{align*}
{\color{greenunder}\text{for a filterable functor }F:}\quad & \text{liftOpt}_{F}:(A\rightarrow\text{Opt}^{B})\rightarrow F^{A}\rightarrow F^{B}\quad,\\
{\color{greenunder}\text{for a filterable contrafunctor }F:}\quad & \text{liftOpt}_{F}:(A\rightarrow\text{Opt}^{B})\rightarrow F^{B}\rightarrow F^{A}\quad,\\
{\color{greenunder}\text{for a monad }F:}\quad & \text{flm}_{F}:(A\rightarrow F^{B})\rightarrow F^{A}\rightarrow F^{B}\quad.
\end{align*}
The laws were equivalently written in terms of natural transformations
(\lstinline!deflate!, \lstinline!inflate!, \lstinline!flatten!):
\begin{align*}
{\color{greenunder}\text{for a filterable functor }F:}\quad & \text{deflate}_{F}:F^{\text{Opt}^{A}}\rightarrow F^{A}\quad,\\
{\color{greenunder}\text{for a filterable contrafunctor }F:}\quad & \text{inflate}_{F}:F^{A}\rightarrow F^{\text{Opt}^{A}}\quad,\\
{\color{greenunder}\text{for a monad }F:}\quad & \text{ftn}_{F}:F^{F^{A}}\rightarrow F^{A}\quad.
\end{align*}
How can the liftings be \emph{equivalent} to their corresponding natural
transformations, which have fewer type parameters and simpler types?
The equations relating these functions have a clear pattern:
\begin{align*}
 & \text{deflate}_{F}=\text{liftOpt}_{F}(\text{id})\quad,\quad\quad\text{liftOpt}_{F}(f)=f^{\uparrow F}\bef\text{deflate}\quad,\\
 & \text{inflate}_{F}=\text{liftOpt}_{F}(\text{id})\quad,\quad\quad\text{liftOpt}_{F}(f)=\text{inflate}\bef f^{\downarrow F}\quad,\\
 & \text{ftn}_{F}=\text{flm}_{F}(\text{id})\quad,\quad\quad\text{flm}_{F}(f)=f^{\uparrow F}\bef\text{ftn}_{F}\quad.
\end{align*}
The pattern is that the code of the lifting-like function contains
both the functionality of \lstinline!map! (lifting the function $f$
to $f^{\uparrow F}$ or $f^{\downarrow F}$) and the functionality
of the corresponding natural transformation. Setting $f$ to an identity
function will cancel the lifting (since $\text{id}^{\uparrow F}=\text{id}$
and $\text{id}^{\downarrow F}=\text{id}$), so that only the functionality
of the natural transformation remains.

We have proved the equivalence of lifting-like functions and their
corresponding natural transformations for filterable functors in Statement~\ref{subsec:Statement-liftOpt-equivalent-to-deflate}
and for monads in Statement~\ref{subsec:Statement-flatten-equivalent-to-flatMap}.
Is it just a coincidence that these functions are equivalent for filterable
functors and for monads, or are these properties special cases of
a general construction? To generalize the type signatures of \lstinline!deflate!
and \lstinline!flatten!, consider arbitrary functors $F$ and $G$,
and a natural transformation
\[
\text{tr}:F^{G^{A}}\rightarrow F^{A}\quad.
\]
A lifting-like function corresponding to this natural transformation
is defined by
\begin{equation}
\text{ftr}:(A\rightarrow G^{B})\rightarrow F^{A}\rightarrow F^{B}\quad,\quad\quad\text{ftr}\,(f^{:A\rightarrow G^{B}})\triangleq f^{\uparrow F}\bef\text{tr}\quad,\label{eq:define-ftr-via-tr}
\end{equation}
which reproduces the definitions for filterable functors with $G=\text{Opt}$
and for monads with $G=F$.

By setting $f=\text{id}$ in Eq.~(\ref{eq:define-ftr-via-tr}), we
find that $\text{tr}=\text{ftr}\,(\text{id})$. When are \lstinline!tr!
and \lstinline!ftr! equivalent?

\subsubsection{Statement \label{subsec:Statement-tr-equivalent-to-ftr}\ref{subsec:Statement-tr-equivalent-to-ftr}}

The natural transformation \lstinline!tr! is equivalent to the lifting-like
function \lstinline!ftr! via:

\begin{wrapfigure}{l}{0.3\columnwidth}%
\vspace{-1.6\baselineskip}

\[
\xymatrix{\xyScaleY{0.2pc}\xyScaleX{2.8pc} & F^{G^{B}}\ar[rd]\sp(0.5){\ \text{tr}\ }\\
F^{A}\ar[ru]\sp(0.5){(f^{:A\rightarrow G^{B}})^{\uparrow F}~\ }\ar[rr]\sb(0.5){\text{ftr}\,(f^{:A\rightarrow G^{B}})\,} &  & F^{B}
}
\]
\vspace{-0.6\baselineskip}
\end{wrapfigure}%

~\vspace{-0.6\baselineskip}
\begin{equation}
\text{ftr}\,(f)=f^{\uparrow F}\bef\text{tr}\quad,\quad\quad\text{tr}=\text{ftr}\,(\text{id})\quad,\label{eq:define-tr-via-ftr}
\end{equation}
if \lstinline!ftr! obeys the naturality law with respect to the type
parameter $A$:
\begin{equation}
g^{\uparrow F}\bef\text{ftr}\left(f\right)=\text{ftr}\left(g\bef f\right)\quad.\label{eq:ftr-left-naturality-law}
\end{equation}


\subparagraph{Proof}

We need to derive the equivalence between \lstinline!tr! and \lstinline!ftr!
in both directions:

\textbf{(a)} Given a function \lstinline!tr!, we first define \lstinline!ftr!
via Eq.~(\ref{eq:define-ftr-via-tr}) and then define a new function
\lstinline!tr!$^{\prime}$ via Eq.~(\ref{eq:define-tr-via-ftr}).
We then show that \lstinline!tr!$^{\prime}$ equals \lstinline!tr!:
\[
\text{tr}^{\prime}=\text{ftr}\left(\text{id}\right)=\gunderline{\text{id}^{\uparrow F}}\bef\text{tr}=\text{tr}\quad.
\]

For the function \lstinline!ftr! defined via \lstinline!tr!, the
naturality law~(\ref{eq:ftr-left-naturality-law}) holds automatically:
\[
g^{\uparrow F}\bef\text{ftr}\left(f\right)=\gunderline{g^{\uparrow F}\bef f^{\uparrow F}}\bef\text{tr}=(g\bef f)^{\uparrow F}\bef\text{tr}=\text{ftr}\left(g\bef f\right)\quad.
\]

\textbf{(b)} Given a function \lstinline!ftr! that satisfies the
law~(\ref{eq:ftr-left-naturality-law}), we define \lstinline!tr!
via Eq.~(\ref{eq:define-tr-via-ftr}) and then define a new function
\lstinline!ftr!$^{\prime}$ via Eq.~(\ref{eq:define-ftr-via-tr})
. We then show that \lstinline!ftr!$^{\prime}$ equals \lstinline!ftr!:
for an arbitrary $f^{:A\rightarrow G^{B}}$, write
\begin{align*}
{\color{greenunder}\text{expect to equal }\text{ftr}\left(f\right):}\quad & \text{ftr}^{\prime}(f)=f^{\uparrow F}\bef\text{tr}=f^{\uparrow F}\bef\text{ftr}\left(\text{id}\right)\\
{\color{greenunder}\text{naturality law~(\ref{eq:ftr-left-naturality-law})}:}\quad & =\text{ftr}\left(f\bef\text{id}\right)=\text{ftr}(f)\quad.
\end{align*}

The full equivalence between \lstinline!tr! and \lstinline!ftr!
would not hold without assuming the naturality law~(\ref{eq:ftr-left-naturality-law}).
To build intuition for that fact, consider that \lstinline!ftr! has
a more complicated type signature with one more type parameter than
\lstinline!tr!. So, in general there are \textsf{``}many more\textsf{''} possible
functions with the type of \lstinline!ftr!. The imposed naturality
law~(\ref{eq:ftr-left-naturality-law}) constrains the code of \lstinline!ftr!
so much that all possible functions \lstinline!ftr! satisfying Eq.~(\ref{eq:ftr-left-naturality-law})
are in a $1$-to-$1$ correspondence with all possible functions \lstinline!tr!.

A similar statement can be proved for contrafunctors $F$, by considering
the type signatures
\[
\text{tr}:F^{A}\rightarrow F^{G^{A}}\quad,\quad\quad\text{ftr}:(A\rightarrow G^{B})\rightarrow F^{B}\rightarrow F^{A}\quad.
\]
Finally, a generalization is also possible with functors $F$ and
the type signatures
\[
\text{tr}:F^{A}\rightarrow F^{G^{A}}\quad,\quad\quad\text{ftr}:(G^{A}\rightarrow B)\rightarrow F^{A}\rightarrow F^{B}\quad.
\]
By referring to these constructions, we can omit detailed proofs of
equivalence in all such cases.

\subsection{Monads, effects, and runners}

The main advantage of using monads is the ability to compose \textsf{``}monadic
programs\index{monadic program}\textsf{''} (i.e., values of type $M^{A}$
for some monad $M$). For list-like and tree-like monads $M$, a value
of type $M^{A}$ represents a collection of values of type $A$ and
is the desired result of nested iterations. The same applies to pass/fail
monads: e.g., a value of type \lstinline!Try[A]! holds either a result
or information about a failure, which we also need to use. However,
for most other monads $M$, a monadic program $m:M^{A}$ represents
a single value of type $A$ held by an \textsf{``}effectful wrapper\textsf{''} of
some sort. To get a useful result, we usually need to extract that
value of type $A$ from the wrapper.

To see how this works in general, consider monads of function type
(such as \lstinline!Reader!, \lstinline!State!, and \lstinline!Cont!).
These monads delay their computations until a runner is applied. A
monadic program $m:M^{A}$ is a function whose body somehow wraps
a value of type $A$, and a runner extracts that value. The function-type
monads are often defined as case classes with a single part called
\lstinline!run!, for example:
\begin{lstlisting}
final case class Reader[Z, A](run: Z => A)
final case class State[S, A](run: S => (A, S))
final case class Cont[R, A](run: (A => R) => R)
\end{lstlisting}
In Scala syntax, this makes monadic programs appear to have a method
called \lstinline!run!:
\begin{lstlisting}
val s: State[S, A] = for { ... } yield { ... }   // A monadic program in the State monad.
val init: S = ???                                // An initial state.
val result: A = s.run(init)._1                   // Run the monadic program and extract the result.
\end{lstlisting}
We can package this code into a \lstinline!runner! function:
\begin{lstlisting}
def runner[S, A](init: S): State[S, A] => A = _.run(init)._1
\end{lstlisting}
The runner for the \lstinline!State! monad performs all the state
updates contained in a monadic program (\lstinline!s: State[S, A]!)
in order to compute a final result value of type $A$. One could say
that the runner \textsf{``}runs the effects\textsf{''} in order to extract the result
value.

These examples motivate a general definition: A \textbf{runner}\index{monads!runner|textit}
for a monad $M$ is a function of type $M^{A}\rightarrow A$, which
we will denote by $\theta^{A}:M^{A}\rightarrow A$.

To be useful in practice, a runner $\theta$ must satisfy certain
laws. To motivate those laws, consider how we would use runners with
a monadic program $m:M^{B}$ that is composed from two parts: the
first part is a monadic program $m_{1}:M^{A}$, and the second part
is a function $m_{2}:A\rightarrow M^{B}$ that depends on the result
(of type $A$) of the first monadic program.

\begin{wrapfigure}{l}{0.4\columnwidth}%
\vspace{-0.85\baselineskip}

\begin{lstlisting}
val m = for {  // m == m1.flatMap(m2)
  x <- m1
  y <- m2(x)
} yield y
\end{lstlisting}
\vspace{-0.6\baselineskip}
\end{wrapfigure}%

\noindent The composition of $m_{1}$ and $m_{2}$ can be written
as a functor block or as an application of the \lstinline!flatMap!
method,
\begin{equation}
m=m_{1}\triangleright\text{flm}_{M}(m_{2})\quad.\label{eq:monad-runners-derivation1}
\end{equation}
\vspace{-1.2\baselineskip}

We may imagine that $\theta\left(m\right)$ first runs the effects
of $m_{1}$ obtaining a value $x$, and then runs the effects of $m_{2}(x)$
obtaining a value $y$. So, it is natural to require that a runner
$\theta$ applied to $m$ should give the same results as applying
$\theta$ to $m_{1}$, which extracts a value $x$, and then applying
the runner to $m_{2}(x)$. We can formulate this requirement as a
law called the runner\textsf{'}s \index{composition law!of monad runners}\textbf{composition
law},

\begin{wrapfigure}{l}{0.4\columnwidth}%
\vspace{-0.85\baselineskip}

\begin{lstlisting}
runner(m) == runner(m2(runner(m1)))
\end{lstlisting}
\vspace{-0.7\baselineskip}
\end{wrapfigure}%

~\vspace{-0.4\baselineskip}
\[
m\triangleright\theta=m_{1}\triangleright\theta\triangleright m_{2}\triangleright\theta\quad.
\]
Substituting $m$ from Eq.~(\ref{eq:monad-runners-derivation1}),
we get $m_{1}\triangleright\text{flm}_{M}(m_{2})\bef\theta=m_{1}\triangleright\theta\bef m_{2}\bef\theta$.
Since this equation must hold for any $m_{1}$, we can simplify it
to
\[
\text{flm}_{M}(m_{2})\bef\theta=\theta\bef m_{2}\bef\theta\quad.
\]

Let us reformulate the composition law in terms of the monad $M$\textsf{'}s
\lstinline!flatten! method:
\[
m_{2}^{\uparrow M}\bef\text{ftn}_{M}\bef\theta=\theta\bef m_{2}\bef\theta\quad.
\]
We would like to move $m_{2}$ to the left of $\theta$ in the right-hand
side, so that $m_{2}$ could drop out of the equation. To interchange
the order of composition $\theta\bef m_{2}$, we assume that a naturality
law\index{naturality law!of monad runners} for $\theta$,
\begin{equation}
f^{\uparrow M}\bef\theta=\theta\bef f\quad.\label{eq:runner-naturality-law}
\end{equation}
It follows that $\theta\bef m_{2}\bef\theta=m_{2}^{\uparrow M}\bef\theta\bef\theta$
and that $\theta\bef\theta=\theta^{\uparrow M}\bef\theta$. The runner\textsf{'}s
composition law becomes:

\begin{wrapfigure}{l}{0.2\columnwidth}%
\vspace{-1.75\baselineskip}

\[
\xymatrix{\xyScaleY{1.5pc}\xyScaleX{2.3pc}M^{M^{A}}\ar[d]\sb(0.5){\text{ftn}_{M}}\ar[r]\sp(0.5){\theta^{\uparrow M}}\sb(0.5){\theta^{M^{A}}} & M^{A}\ar[d]\sb(0.45){\theta}\\
M^{A}\ar[r]\sp(0.5){\theta} & A
}
\]
\vspace{-0\baselineskip}
\end{wrapfigure}%

~\vspace{-0.4\baselineskip}
\begin{equation}
\text{ftn}_{M}\bef\theta=\theta\bef\theta=\theta^{\uparrow M}\bef\theta\quad.\label{eq:runner-composition-law}
\end{equation}

\noindent Another clearly motivated requirement for runners is that
\lstinline!pure(x)!, a monadic value with an \textsf{``}empty effect\textsf{''},
should be correctly handled by the runner:
\[
x\triangleright\text{pu}_{M}\triangleright\theta=x\quad,\quad\text{or equivalently:}\quad\text{pu}_{M}\bef\theta=\text{id}\quad.
\]
This is the \index{identity laws!of monad runner}\textbf{identity
law} of monad runners.

If a runner has purely functional code (such as the runner for the
\lstinline!State! monad shown above), the naturality law~(\ref{eq:runner-naturality-law})
will hold automatically due to the parametricity theorem. However,
monad runners are not always purely functional. For example, the runner
for the continuation monad shown in Section~\ref{subsec:The-continuation-monad}
uses Scala\textsf{'}s \lstinline!Future! and \lstinline!Promise! classes,
which are not purely functional. (Nevertheless, the identity and composition
laws hold for that runner.)

We have argued that list-like, tree-like, and pass/fail monads do
not need runners; but in fact, those monads \emph{cannot} have lawful
runners. For instance, the \lstinline!Option! monad cannot have a
purely functional runner: a function $\theta^{A}:\bbnum 1+A\rightarrow A$
must produce a value of type $A$ even if the \lstinline!Option!
value is empty, but it is impossible to produce a value of an arbitrary
type $A$ from scratch using purely functional code. For the \lstinline!Option!
monad and other pass/fail monads, we could only use runners $\theta^{A}$
that work for a specific type $A$, for example:
\begin{lstlisting}
def runner: Option[Int] => Int = _.getOrElse(0) // For empty Option values, return a default.
\end{lstlisting}

Even if we restrict all types to \lstinline!Int!, this runner will
fail to obey the composition law:
\begin{lstlisting}
val m1: Option[Int] = None
val m2: Int => Option[Int] = { x => Some(x + 1) }
val m: Option[Int] = for { x <- m1; y <- m2(x) } yield y

scala> runner(m)   // Composition law: runner(m) == runner(m2(runner(m1))).
res0: Int = 0

scala> runner(m2(runner(m1)))
res1: Int = 1
\end{lstlisting}
Similar arguments apply to list-like and tree-like monads. These monads
may have an empty value, which cannot be correctly handled by a runner
$\theta^{A}$ whose result must be of parametric type $A$. 

A solution is to generalize the notion of runner from a function of
type $M^{A}\rightarrow A$ to a function of type $M^{A}\rightarrow N^{A}$
where $N$ is another monad (the \textsf{``}target\textsf{''} monad of the runner).
For example, if $M$ is a pass/fail monad, we can choose the target
monad as $N^{A}=E+A$ where a fixed type $E$ represents error information.
We can then define a generalized runner for the \lstinline!Option!
monad like this:

\begin{wrapfigure}{l}{0.43\columnwidth}%
\vspace{-0.85\baselineskip}

\begin{lstlisting}
val error: E = ... // Describe the error.
def run[A]: Option[A] => Either[E, A] = {
  case None    => Left(error)
  case Some(a) => Right(a)
}
\end{lstlisting}
\vspace{-2.2\baselineskip}
\end{wrapfigure}%

~\vspace{-0.4\baselineskip}
\[
\theta^{:\bbnum 1+A\rightarrow E+A}\triangleq\begin{array}{|c||cc|}
 & E & A\\
\hline \bbnum 1 & \_\rightarrow\text{error} & \bbnum 0\\
A & \bbnum 0 & \text{id}
\end{array}\quad.
\]
In the next section, we will formulate the laws for such maps between
monads.

\subsection{Monads in category theory. Monad morphisms\label{subsec:Monads-in-category-theory-monad-morphisms}}

For any monad $M$, one defines a category, called the $M$-\index{Kleisli!category}Kleisli
category, whose objects are all types (\lstinline!Int!, \lstinline!String!,
etc.) and whose morphisms between types $A$ and $B$ are Kleisli
functions of type $A\rightarrow M^{B}$. 

One axiom of a category requires us to have an identity morphism $A\rightarrow M^{A}$
for every object $A$; this is the monad $M$\textsf{'}s \lstinline!pure!
method, $\text{pu}_{M}:A\rightarrow M^{A}$. Another axiom is the
associativity of morphism composition operation, which must combine
functions of types $A\rightarrow M^{B}$ and $B\rightarrow M^{C}$
into a function of type $A\rightarrow M^{C}$. The Kleisli composition
$\diamond_{_{M}}$ is precisely that operation, and its associativity
law, $f\diamond_{_{M}}(g\diamond_{_{M}}h)=(f\diamond_{_{M}}g)\,\diamond_{_{M}}h$,
is equivalent to a law of \lstinline!flatMap! (Statements~\ref{subsec:Statement-associativity-law-for-kleisli}\textendash \ref{subsec:Statement-equivalence-kleisli-laws-and-flatMap-laws}).

So, a functor $M$ is a monad if and only if the corresponding $M$-Kleisli
category is lawful. This is an economical way of formulating the monad
laws; the only information specific to monads is the type signature
$A\rightarrow M^{B}$ for the $M$-Kleisli morphisms.

We have seen that, for some monads, proofs of the laws are easier
when written in terms of Kleisli morphisms. It turns out that the
properties of monad runners also have a concise formulation in the
language of categories.

A monad $M$\textsf{'}s \lstinline!pure! method has type $A\rightarrow M^{A}$,
while a runner $\theta_{M}$ has type $M^{A}\rightarrow A$. Since
the type parameter $A$ itself can be viewed as the identity monad
$\text{Id}^{A}\triangleq A$, we can write the types as
\[
\text{pu}_{M}:\text{Id}^{A}\rightarrow M^{A}\quad,\quad\quad\theta_{M}:M^{A}\rightarrow\text{Id}^{A}\quad.
\]
 These two types can be generalized to a transformation between two
monads $M$ and $N$,
\[
\phi:M^{A}\rightarrow N^{A}\quad.
\]
As we have seen in the previous section, some monads $M$ require
runners of this more general type, rather than of type $M^{A}\rightarrow A$.

Another use case for the type $M^{A}\rightarrow N^{A}$ comes from
our code for the continuation monad\textsf{'}s runner. The code first transforms
a value of type \lstinline!Cont[R, A]! into a \lstinline!Future[A]!
and then waits for the \lstinline!Future! to complete. So, \lstinline!Cont!\textsf{'}s
runner can be seen as a composition of two transformations:
\[
\xymatrix{\xyScaleY{0.8pc}\xyScaleX{4.5pc}\text{Cont}^{R,A}\ar[r]\sp(0.5){\theta_{\text{Cont-Future}}} & \text{Future}^{A}\ar[r]\sp(0.6){\theta_{\text{Future}}} & A & \theta_{\text{Cont}}=\theta_{\text{Cont-Future}}\bef\theta_{\text{Future}}\quad.}
\]
The intermediate \textsf{``}generalized runner\textsf{''} $\theta_{\text{Cont-Future}}$
converts continuation-based monadic programs into \lstinline!Future!-based
ones. That conversion will be compatible with the way we write and
refactor functor blocks only if we impose laws similar to the laws
of runners shown in the previous section. The \textsf{``}generalized runners\textsf{''}
are called monad morphisms. The following definition states their
laws:

\subsubsection{Definition \label{subsec:Definition-monad-morphism}\ref{subsec:Definition-monad-morphism}}

A natural transformation $\phi^{A}:M^{A}\rightarrow N^{A}$, also
denoted by $\phi:M\leadsto N$, is called a \textbf{monad morphism}\index{monad morphism}
between monads $M$ and $N$ if the following two laws hold:
\begin{align}
{\color{greenunder}\text{identity law of }\phi:}\quad & \text{pu}_{M}\bef\phi=\text{pu}_{N}\quad,\label{eq:monad-morphism-identity-law}\\
{\color{greenunder}\text{composition law of }\phi:}\quad & \text{ftn}_{M}\bef\phi=\phi^{\uparrow M}\bef\phi\bef\text{ftn}_{N}\quad.\label{eq:monad-morphism-composition-law-using-ftn}
\end{align}
\vspace{-1.2\baselineskip}
\[
\xymatrix{\xyScaleY{1.2pc}\xyScaleX{4.8pc} & A\ar[d]\sp(0.5){\ \text{pu}_{M}\ }\ar[ld]\sb(0.5){\text{pu}_{N}} & M^{M^{A}}\ar[d]\sb(0.5){\phi^{\uparrow M}}\ar[r]\sp(0.5){\text{ftn}_{M}} & M^{A}\ar[rd]\sp(0.5){\phi}\\
N^{A} & M^{A}\ar[l]\sb(0.42){\phi} & M^{N^{A}}\ar[r]\sp(0.5){\phi^{N^{A}}} & N^{N^{A}}\ar[r]\sp(0.5){\text{ftn}_{N}} & N^{A}
}
\]

The composition law can be equivalently expressed using the \lstinline!flatMap!
method:
\begin{equation}
\text{flm}_{M}(f^{:A\rightarrow M^{B}})\bef\phi^{:M^{B}\rightarrow N^{B}}=\phi\bef\text{flm}_{N}(f\bef\phi)\quad.\label{eq:monad-morphism-composition-law-using-flatMap}
\end{equation}

In terms of the Kleisli composition operations $\diamond_{_{M}}$
and $\diamond_{_{N}}$, the composition law is
\[
(f^{:A\rightarrow M^{B}}\bef\phi^{:M^{B}\rightarrow N^{B}})\diamond_{_{N}}(g^{:B\rightarrow M^{C}}\bef\phi^{:M^{C}\rightarrow N^{C}})=(f\diamond_{_{M}}g)\bef\phi^{:M^{C}\rightarrow N^{C}}\quad.
\]
This formulation shows more visually that a monad morphism $\phi:M\leadsto N$
replaces $M$-effects by $N$-effects while preserving the composition
of effectful computations.

The name \textsf{``}monad morphism\textsf{''} is motivated by considering the \emph{category
of monads}.\index{monads!category of}\index{category of monads}
The objects of that category are all the possible monads (type constructors
such as \lstinline!Option!, \lstinline!Try!, etc.). The morphisms
between objects $M$ and $N$ of that category are monad morphisms
$M\leadsto N$ as defined above: natural transformations that preserve
the structure of the monadic operations.

At the same time, a monad morphism $\phi$ can be viewed as a correspondence
$g=f\bef\phi$ between Kleisli functions $f:A\rightarrow M^{B}$ and
$g:A\rightarrow N^{B}$. The laws of monad morphisms guarantee that
the mapping $\phi$ is compatible with the Kleisli composition operations
$\diamond_{_{M}}$ and $\diamond_{_{N}}$. So, it can be seen also
as expressing a (categorical) functor between the $M$-Kleisli and
the $N$-Kleisli categories.

Monad morphisms between arbitrary monads will be also used in Chapters~\ref{chap:Free-type-constructions}
and~\ref{chap:monad-transformers}. To build up more intuition, let
us look at some examples of monad morphisms.

\subsubsection{Example \label{subsec:Example-monad-morphism-either-option}\ref{subsec:Example-monad-morphism-either-option}\index{solved examples}}

We would like to define a function $\phi^{A}:Z+A\rightarrow\bbnum 1+A$
as a monad morphism between the \lstinline!Either! and \lstinline!Option!
monads. The implementation of $\phi$ is:

\begin{wrapfigure}{l}{0.5\columnwidth}%
\vspace{-0.75\baselineskip}

\begin{lstlisting}
def toOption[Z, A]: Either[Z, A] => Option[A] = {
  case Left(z)    => None
  case Right(a)   => Some(a)
}
\end{lstlisting}
\vspace{-1.7\baselineskip}
\end{wrapfigure}%

~\vspace{-0.7\baselineskip}
\[
\phi\triangleq\,\begin{array}{|c||cc|}
 & \bbnum 1 & A\\
\hline Z & \_\rightarrow1 & \bbnum 0\\
A & \bbnum 0 & \text{id}
\end{array}\quad.
\]

To verify the identity law~(\ref{eq:monad-morphism-identity-law}):
\[
\text{pu}_{\text{Either}}\bef\phi=\,\begin{array}{|c||cc|}
 & Z & A\\
\hline A & \bbnum 0 & \text{id}
\end{array}\,\bef\,\begin{array}{|c||cc|}
 & \bbnum 1 & A\\
\hline Z & \_\rightarrow1 & \bbnum 0\\
A & \bbnum 0 & \text{id}
\end{array}\,=\,\begin{array}{|c||cc|}
 & \bbnum 1 & A\\
\hline A & \bbnum 0 & \text{id}
\end{array}\,=\text{pu}_{\text{Opt}}\quad.
\]

To verify the composition law~(\ref{eq:monad-morphism-composition-law-using-ftn}),
show that both sides are equal:
\begin{align*}
{\color{greenunder}\text{left-hand side}:}\quad & \text{ftn}_{\text{Either}}\bef\phi=\,\begin{array}{|c||cc|}
 & Z & A\\
\hline Z & \text{id} & \bbnum 0\\
Z & \text{id} & \bbnum 0\\
A & \bbnum 0 & \text{id}
\end{array}\,\bef\,\begin{array}{|c||cc|}
 & \bbnum 1 & A\\
\hline Z & \_\rightarrow1 & \bbnum 0\\
A & \bbnum 0 & \text{id}
\end{array}\,=\,\begin{array}{|c||cc|}
 & \bbnum 1 & A\\
\hline Z & \_\rightarrow1 & \bbnum 0\\
Z & \_\rightarrow1 & \bbnum 0\\
A & \bbnum 0 & \text{id}
\end{array}\quad,\\
{\color{greenunder}\text{right-hand side}:}\quad & \phi^{\uparrow\text{Either}}\bef\phi\bef\text{ftn}_{\text{Opt}}=\,\begin{array}{|c||ccc|}
 & Z & \bbnum 1 & A\\
\hline Z & \text{id} & \bbnum 0 & \bbnum 0\\
Z & \bbnum 0 & \_\rightarrow1 & \bbnum 0\\
A & \bbnum 0 & \bbnum 0 & \text{id}
\end{array}\,\bef\,\begin{array}{|c||ccc|}
 & \bbnum 1 & \bbnum 1 & A\\
\hline Z & \_\rightarrow1 & \bbnum 0 & \bbnum 0\\
\bbnum 1 & \bbnum 0 & \text{id} & \bbnum 0\\
A & \bbnum 0 & \bbnum 0 & \text{id}
\end{array}\,\bef\,\begin{array}{|c||cc|}
 & \bbnum 1 & A\\
\hline \bbnum 1 & \text{id} & \bbnum 0\\
\bbnum 1 & \text{id} & \bbnum 0\\
A & \bbnum 0 & \text{id}
\end{array}\\
 & \quad=\,\begin{array}{|c||ccc|}
 & \bbnum 1 & \bbnum 1 & A\\
\hline Z & \_\rightarrow1 & \bbnum 0 & \bbnum 0\\
Z & \bbnum 0 & \_\rightarrow1 & \bbnum 0\\
A & \bbnum 0 & \bbnum 0 & \text{id}
\end{array}\,\bef\,\begin{array}{|c||cc|}
 & \bbnum 1 & A\\
\hline \bbnum 1 & \text{id} & \bbnum 0\\
\bbnum 1 & \text{id} & \bbnum 0\\
A & \bbnum 0 & \text{id}
\end{array}\,=\,\begin{array}{|c||cc|}
 & \bbnum 1 & A\\
\hline Z & \_\rightarrow1 & \bbnum 0\\
Z & \_\rightarrow1 & \bbnum 0\\
A & \bbnum 0 & \text{id}
\end{array}\quad.
\end{align*}

This monad morphism $\phi$ maps the \lstinline!Either!-effect (error
information) to the \lstinline!Option!-effect (absence of value)
by discarding the error information. The laws of the monad morphism
guarantee that composition of \lstinline!Either!-effects is mapped
into composition of \lstinline!Option!-effects. For instance, if
some computations caused an error encapsulated by \lstinline!Either!,
the corresponding value after $\phi$ will be an empty \lstinline!Option!
(i.e., \lstinline!None!). 

The function $\phi$ is so simple that the correspondence of effects
appears to be automatic. The next example shows a monad morphism that
translates effects in a nontrivial way.

\subsubsection{Example \label{subsec:monad-morphism-writer-state}\ref{subsec:monad-morphism-writer-state}}

A monad morphism between the \lstinline!Writer! and the \lstinline!Cont!
monads can be defined by
\begin{lstlisting}
def toCont[W: Monoid, A]: ((A, W)) => (A => W) => W = { case (a, w) => k => k(a) |+| w }
\end{lstlisting}
\[
\phi:A\times W\rightarrow\left(A\rightarrow W\right)\rightarrow W\quad,\quad\quad\phi\triangleq a^{:A}\times w^{:W}\rightarrow k^{:A\rightarrow W}\rightarrow k\left(a\right)\oplus w\quad,
\]
where the fixed type $W$ is a monoid with a binary operation $\oplus$
and empty value $e$. The continuation monad\textsf{'}s callback returns a
value of type $W$ that depends on the output $w$ from the \lstinline!Writer!
monad.

To verify the identity law, use the definitions of \lstinline!pure!
for the \lstinline!Writer! and \lstinline!Cont! monads:
\begin{align*}
 & \text{pu}_{\text{Writer}}\bef\phi=(a\rightarrow a\times e)\bef(a\times w\rightarrow k\rightarrow k\left(a\right)\oplus w)\\
{\color{greenunder}\text{compute composition}:}\quad & =a\rightarrow k\rightarrow k\left(a\right)\,\gunderline{\oplus\,e}=a\rightarrow k\rightarrow k\left(a\right)=\text{pu}_{\text{Cont}}\quad.
\end{align*}

To verify the composition law, we need an implementation of \lstinline!flatten!
for the \lstinline!Cont! monad:
\begin{lstlisting}
def flatten[W, A]: ((((A => W) => W) => W) => W) => (A => W) => W = { g => k => g(c => c(k)) }
\end{lstlisting}
\[
\text{ftn}_{\text{Cont}}=g^{:\left(\left(\left(A\rightarrow W\right)\rightarrow W\right)\rightarrow W\right)\rightarrow W}\rightarrow k^{:A\rightarrow W}\rightarrow g\,(c^{:\left(A\rightarrow W\right)\rightarrow W}\rightarrow c\left(k\right))\quad.
\]
Now we show that the two sides of the law~(\ref{eq:monad-morphism-composition-law-using-ftn})
reduce to the same function:
\begin{align*}
{\color{greenunder}\text{left-hand side}:}\quad & \text{ftn}_{\text{Writer}}\bef\phi=(a\times u\times w\rightarrow a\times(u\oplus w))\bef(a\times w\rightarrow k\rightarrow k\left(a\right)\oplus w)\\
 & =a\times u\times w\rightarrow k\rightarrow k\left(a\right)\oplus u\oplus w\quad,\\
{\color{greenunder}\text{right-hand side}:}\quad & \phi^{\uparrow\text{Writer}}\bef\phi^{\text{Cont}^{W,A}}\bef\text{ftn}_{\text{Cont}}\\
 & =\gunderline{(a\times u\times w\rightarrow(k\rightarrow k\left(a\right)\oplus u)\times w)\bef(c\times w\rightarrow h\rightarrow h\left(c\right)\oplus w)}\bef\text{ftn}_{\text{Cont}}\\
{\color{greenunder}\text{compute composition}:}\quad & =(a\times u\times w\rightarrow h\rightarrow h\left(k\rightarrow k\left(a\right)\oplus u\right)\oplus w)\bef\gunderline{\text{ftn}_{\text{Cont}}}\\
 & =(a\times u\times w\rightarrow h\rightarrow h\left(k\rightarrow k\left(a\right)\oplus u\right)\oplus w)\bef\left(g\rightarrow p\rightarrow g(c\rightarrow c\left(p\right))\right)\\
{\color{greenunder}\text{compute composition}:}\quad & =a\times u\times w\rightarrow p\rightarrow\gunderline{(c\rightarrow c\left(p\right))(k\rightarrow k\left(a\right)\oplus u)}\oplus w\\
 & =a\times u\times w\rightarrow p\rightarrow p\left(a\right)\oplus u\oplus w\quad.
\end{align*}

We conclude this section by proving some properties of monad morphisms.

\subsubsection{Statement \label{subsec:Statement-flatMap-formulation-of-monad-morphism}\ref{subsec:Statement-flatMap-formulation-of-monad-morphism}}

If a function $\phi^{A}:M^{A}\rightarrow N^{A}$ satisfies Eqs.~(\ref{eq:monad-morphism-identity-law})
and~(\ref{eq:monad-morphism-composition-law-using-flatMap}) then
\textbf{(a)} $\phi$ is a natural transformation, and \textbf{(b)}
$\phi$ also satisfies Eq.~(\ref{eq:monad-morphism-composition-law-using-ftn}).

\subparagraph{Proof}

\textbf{(a)} The naturality law of $\phi$,
\begin{equation}
(g^{:A\rightarrow B})^{\uparrow M}\bef\phi=\phi\bef g^{\uparrow N}\quad,\label{eq:monad-morphism-naturality-law}
\end{equation}
is derived from Eq.~(\ref{eq:monad-morphism-composition-law-using-flatMap})
by setting $f^{:A\rightarrow M^{B}}\triangleq g^{:A\rightarrow B}\bef\text{pu}_{M}^{:B\rightarrow M^{B}}$:
\begin{align*}
{\color{greenunder}\text{left-hand side of Eq.~(\ref{eq:monad-morphism-composition-law-using-flatMap})}:}\quad & \text{flm}_{M}(f)\bef\phi=\gunderline{\text{flm}_{M}(f}\bef\text{pu}_{M})\bef\phi\\
{\color{greenunder}\text{left naturality of }\text{flm}_{M}:}\quad & \quad=f^{\uparrow M}\bef\gunderline{\text{flm}_{M}(\text{pu}_{M})}\bef\phi\\
{\color{greenunder}\text{right identity law of }\text{flm}_{M}:}\quad & \quad=f^{\uparrow M}\bef\phi\quad,\\
{\color{greenunder}\text{right-hand side of Eq.~(\ref{eq:monad-morphism-composition-law-using-flatMap})}:}\quad & \phi\bef\text{flm}_{N}(f\bef\phi)=\phi\bef\text{flm}_{N}(g\bef\gunderline{\text{pu}_{M}\bef\phi})\\
{\color{greenunder}\text{identity law~(\ref{eq:monad-morphism-identity-law})}:}\quad & \quad=\phi\bef\text{flm}_{N}(g\bef\text{pu}_{N})\\
{\color{greenunder}\text{left naturality of }\text{flm}_{N}:}\quad & \quad=\phi\bef g^{\uparrow N}\bef\gunderline{\text{flm}_{N}(\text{pu}_{N})}\\
{\color{greenunder}\text{right identity law of }\text{flm}_{N}:}\quad & \quad=\phi\bef g^{\uparrow N}\quad.
\end{align*}
The two sides of Eq.~(\ref{eq:monad-morphism-composition-law-using-flatMap})
are equal to the two sides of Eq.~(\ref{eq:monad-morphism-naturality-law}).

\textbf{(b)} Substitute the definitions $\text{flm}_{M}(f)=f^{\uparrow M}\bef\text{ftn}_{M}$
and $\text{flm}_{N}(f)=f^{\uparrow N}\bef\text{ftn}_{N}$ into Eq.~(\ref{eq:monad-morphism-composition-law-using-flatMap}):
\begin{align*}
 & f^{\uparrow M}\bef\text{ftn}_{M}\bef\phi=\gunderline{\phi\bef(f\bef\phi)^{\uparrow N}}\bef\text{ftn}_{N}\quad.\\
{\color{greenunder}\text{use Eq.~(\ref{eq:monad-morphism-naturality-law})}:}\quad & =\gunderline{(f\bef\phi)^{\uparrow M}}\bef\phi\bef\text{ftn}_{N}=f^{\uparrow M}\bef\phi^{\uparrow M}\bef\phi\bef\text{ftn}_{M}\quad.
\end{align*}
This equality holds for any $f$, in particular with $f=\text{id}$,
which directly gives Eq.~(\ref{eq:monad-morphism-composition-law-using-ftn}).

\subsubsection{Statement \label{subsec:Statement-monadic-morphism-composition}\ref{subsec:Statement-monadic-morphism-composition}}

If $L$, $M$, $N$ are monads and $\phi:L\leadsto M$ and $\chi:M\leadsto N$
are monad morphisms then the composition $\phi\bef\chi:L\leadsto N$
is also a monad morphism.

\subparagraph{Proof}

The identity law for $\phi\bef\chi$ is verified by:
\begin{align*}
{\color{greenunder}\text{expect to equal }\text{pu}_{N}:}\quad & \gunderline{\text{pu}_{L}\bef(\phi}\bef\chi)\\
{\color{greenunder}\text{identity law for }\phi:}\quad & =\text{pu}_{M}\bef\chi\\
{\color{greenunder}\text{identity law for }\chi:}\quad & =\text{pu}_{N}\quad.
\end{align*}
The composition law for $\phi\bef\chi$ is verified by:
\begin{align*}
{\color{greenunder}\text{expect to equal }\text{ftn}_{L}\bef\phi\bef\chi:}\quad & (\phi\bef\gunderline{\chi)^{\uparrow L}\bef(\phi}\bef\chi)\bef\text{ftn}_{N}\\
{\color{greenunder}\text{naturality of }\phi:}\quad & =\phi^{\uparrow L}\bef\phi\bef\gunderline{\chi^{\uparrow M}\bef\chi\bef\text{ftn}_{N}}\\
{\color{greenunder}\text{composition law for }\chi:}\quad & =\gunderline{\phi^{\uparrow L}\bef\phi\bef\text{ftn}_{M}}\bef\chi\\
{\color{greenunder}\text{composition law for }\phi:}\quad & =\text{ftn}_{L}\bef\phi\bef\chi\quad.
\end{align*}


\subsubsection{Statement \label{subsec:Statement-pure-M-is-monad-morphism}\ref{subsec:Statement-pure-M-is-monad-morphism}}

For any monad $M$, the method $\text{pu}_{M}:A\rightarrow M^{A}$
is a monad morphism $\text{pu}_{M}:\text{Id}\leadsto M$ between the
identity monad and $M$.

\subparagraph{Proof}

The identity law requires $\text{pu}_{\text{Id}}\bef\text{pu}_{M}=\text{pu}_{M}$.
This holds because $\text{pu}_{\text{Id}}=\text{id}$. The composition
law requires $\text{ftn}_{\text{Id}}\bef\text{pu}_{M}=\text{pu}_{M}^{\uparrow\text{Id}}\bef\text{pu}_{M}\bef\text{ftn}_{M}$.
Since $\text{ftn}_{\text{Id}}=\text{id}$, the left-hand side of the
composition law simplifies to $\text{pu}_{M}$. Transform the right-hand
side:
\begin{align*}
{\color{greenunder}\text{expect to equal }\text{pu}_{M}:}\quad & \gunderline{\text{pu}_{M}^{\uparrow\text{Id}}}\bef\text{pu}_{M}\bef\text{ftn}_{M}\\
{\color{greenunder}\text{lifting to the identity functor}:}\quad & =\text{pu}_{M}\bef\gunderline{\text{pu}_{M}\bef\text{ftn}_{M}}\\
{\color{greenunder}\text{left identity law for }M:}\quad & =\text{pu}_{M}\quad.
\end{align*}


\subsubsection{Exercise \label{subsec:Exercise-fmap-is-not-monadic-morphism}\ref{subsec:Exercise-fmap-is-not-monadic-morphism}\index{exercises}}

Suppose $M$ is a given monad, $Z$ is a fixed type, and a \emph{fixed}
value $m_{0}:M^{Z}$ is given.

\textbf{(a)} Consider the function $f$ defined as
\[
f:\left(Z\rightarrow A\right)\rightarrow M^{A}\quad,\quad\quad f\,(q^{:Z\rightarrow A})\triangleq m_{0}\triangleright q^{\uparrow M}\quad.
\]
Prove that $f$ is \emph{not} a monad morphism from the \lstinline!Reader!
monad $R^{A}\triangleq Z\rightarrow A$ to the monad $M^{A}$, despite
having the correct type signature.

\textbf{(b)} Under the same assumptions, consider the function $\phi$
defined as
\[
\phi:(Z\rightarrow M^{A})\rightarrow M^{A}\quad,\quad\quad\phi\,(q^{:Z\rightarrow M^{A}})\triangleq m_{0}\triangleright\text{flm}_{M}(q)\quad.
\]
Show that $\phi$ is \emph{not} a monad morphism from the monad $Q^{A}\triangleq Z\rightarrow M^{A}$
to $M^{A}$.

\subsection{Constructions of polynomial monads\label{subsec:Constructions-of-polynomial-monads}}

\textsf{``}Polynomial monads\textsf{''} are polynomial functors that have lawful monad
methods. The product and co-product constructions allow us to create
polynomial monads via the following operations:
\begin{itemize}
\item Start with $F^{A}\triangleq Z+W\times A$, which is a monad (semimonad)
when $W$ is a monoid (semigroup).
\item Given a polynomial monad $F^{A}$, create the monad $L^{A}\triangleq A+F^{A}$.
\item Given two polynomial monads $F^{A}$ and $G^{A}$, create the monad
$L^{A}\triangleq F^{A}\times G^{A}$.
\item Given a polynomial monad $F^{A}$, create the monad $L^{A}\triangleq F^{Z+W\times A}$
(see Section~\ref{sec:transformers-linear-monads}).
\end{itemize}
It is an open conjecture (no proof is known) that these are the only
constructions available for polynomial monads. If so, we can create
an algorithm that recognizes whether a given polynomial functor can
be made into a monad by a suitable definition of \lstinline!flatten!
and \lstinline!pure!. 

As an example, consider the fact that the polynomial functor $F^{A}\triangleq\bbnum 1+A\times A$
cannot be made into a monad (Exercise~\ref{subsec:Exercise-1-monads-6}).
One can also show that $F^{A}$ cannot be obtained through the monad
constructions listed above. Indeed, the corresponding polynomial $f(x)=1+x^{2}$
does not contain any first powers of $x$. However, the constructions
either start with a polynomial containing $x$, or add $x$, or take
a product of two such polynomials. None of these operations could
cancel first powers of $x$ since all coefficients are types and cannot
be subtracted.

By the same logic, we can conclude that $F^{A}\triangleq\bbnum 1+A\times A\times A$
cannot be obtained through monad constructions. It is likely that
$F^{A}\triangleq\bbnum 1+A\times A\times A$, $F^{A}\triangleq\bbnum 1+A\times A\times A\times A$,
and all other similarly constructed functors are not monads.

\subsection{Constructions of $M$-filterable functors and contrafunctors\label{subsec:Constructions-of-M-filterables}}

In Chapter~\ref{chap:Filterable-functors}, we have used the $\text{Opt}$-Kleisli
category (that is, the $M$-Kleisli category with $M$ set to the
\lstinline!Option! monad) to formulate the laws of filterable (contra)functors.
We found that the laws of a filterable (contra)functor $F$ are equivalent
to the requirement that the function \lstinline!liftOpt! be a lawful
(categorical) functor from the $\text{Opt}$-Kleisli category to an
$F$-lifted category:
\begin{align*}
{\color{greenunder}\text{filterable functor }F:}\quad & \text{liftOpt}_{F}:(A\rightarrow\text{Opt}^{B})\rightarrow F^{A}\rightarrow F^{B}\quad,\\
{\color{greenunder}\text{filterable contrafunctor }F:}\quad & \text{liftOpt}_{F}:(A\rightarrow\text{Opt}^{B})\rightarrow F^{B}\rightarrow F^{A}\quad.
\end{align*}
It is natural to generalize this formulation from the \lstinline!Option!
monad to an arbitrary monad $M$:
\begin{align*}
{\color{greenunder}M\text{-filterable functor }F:}\quad & \text{lift}_{M,F}:(A\rightarrow M^{B})\rightarrow F^{A}\rightarrow F^{B}\quad,\\
{\color{greenunder}M\text{-filterable contrafunctor }F:}\quad & \text{lift}_{M,F}:(A\rightarrow M^{B})\rightarrow F^{B}\rightarrow F^{A}\quad.
\end{align*}
 This gave us the definitions of $M$-filterable functors and contrafunctors.

We have shown some simple examples of $M$-filterable functors in
Statement~\ref{subsec:Statement-examples-of-filterable-contrafunctors}.
Structural analysis can discover other examples of such functors systematically.
As in the case of ordinary filterable functors, it turns out that
we must at the same time analyze $M$-filterable contrafunctors.

In the following constructions, we always assume that $M$ is a fixed,
lawful monad.

We omit the proofs of all following statements because they are fully
analogous to the proofs of filterable functor and contrafunctor constructions
in Sections~\ref{subsec:Constructions-of-filterable-functors} and~\ref{subsec:Constructions-of-filterable-contrafunctors}.
In those proofs, we only used the properties of the functions $\text{liftOpt}_{F}$,
which are fully analogous to the properties of the function $\text{lift}_{M,F}$
except for replacing the \lstinline!Option! monad by the monad $M$
and the operation $\diamond_{_{\text{Opt}}}$ by $\diamond_{_{M}}$.

\paragraph{Type parameters}

A constant functor $F^{A}\triangleq Z$ is $M$-filterable with $\text{lift}_{M,F}(f)=\text{id}$
(Statement~\ref{subsec:Statement-examples-of-filterable-contrafunctors}).
The same statement shows that $F^{A}\triangleq M^{A}\rightarrow Z$
and $F^{A}\triangleq A\rightarrow M^{Z}$ are $M$-filterable contrafunctors.

The monad $M^{A}$ itself is $M$-filterable; $\text{lift}_{M,M}(f)\triangleq\text{flm}_{M}(f)$.

The identity functor is not $M$-filterable except when $M$ is the
identity monad, $M^{A}=\text{Id}^{A}\triangleq A$. (However, with
$M=\text{Id}$, the concept of $M$-filterable functor becomes trivial
because all functors and all contrafunctors are $\text{Id}$-filterable.
So, we will assume that $M\neq\text{Id}$.)

The (contra)functor $F^{A}\triangleq G^{H^{A}}$ is $M$-filterable
when $H$ is $M$-filterable and $G$ is any (contra)functor (Statements~\ref{subsec:Statement-filterable-composition-functors}
and~\ref{subsec:Statement-filterable-contrafunctor-composition}),
where $G$ and $H$ can be functors or contrafunctors independently.

\paragraph{Products}

If $F^{A}$ and $G^{A}$ are $M$-filterable then $L^{A}\triangleq F^{A}\times G^{A}$
is $M$-filterable (Statement~\ref{subsec:Statement-filterable-functor-product}).

\paragraph{Co-products}

If $F^{A}$ and $G^{A}$ are $M$-filterable then $L^{A}\triangleq F^{A}+G^{A}$
is $M$-filterable (Statement~\ref{subsec:Statement-filterable-coproduct}).

\paragraph{Function types}

If $F^{A}$ is an $M$-filterable functor and $G^{A}$ is an $M$-filterable
contrafunctor then $F^{A}\rightarrow G^{A}$ and $G^{A}\rightarrow F^{A}$
are $M$-filterable (contra)functors (Statement~\ref{subsec:Statement-filterable-function-type}
and~\ref{subsec:Statement-function-type-exponential-filterable-contrafunctor}).

The filterable contrafunctor $M^{A}\rightarrow Z$ from Statement~\ref{subsec:Statement-examples-of-filterable-contrafunctors}
is obtained from this construction if we set $F^{A}=M^{A}$ and $G^{A}=Z$;
both $F$ and $G$ are filterable as we have already seen.

\paragraph{Recursive types}

If $S^{A,R}$ is a bifunctor that is $M$-filterable with respect
to $A$, the recursive functor $F^{A}$ defined by the type equation
$F^{A}\triangleq S^{A,F^{A}}$ is $M$-filterable (Statement~\ref{subsec:Statement-filterable-recursive-type-1}).

If $S^{A,R}$ is a profunctor\index{profunctor} contravariant in
$A$ and covariant in $R$, and additionally $S^{\bullet,R}$ is $M$-filterable
(with the type parameter $R$ fixed), then the recursive contrafunctor
$F^{A}\triangleq S^{A,F^{A}}$ is $M$-filterable (Statement~\ref{subsec:Statement-recursive-filterable-contrafunctor}).

In summary, any recursively exponential-polynomial type expression
$F^{A}$ will be an $M$-filterable (contra)functor if it depends
on a type parameter $A$ only through type expressions $M^{A}$ or
$A\rightarrow M^{Z}$ (where $Z$ is a fixed type). While there may
be other $M$-filterable (contra)functors, the structural analysis
covers a broad class of type expressions of the form
\[
S^{M^{A},A\rightarrow M^{Z_{1}},...,A\rightarrow M^{Z_{n}}}\quad,
\]
where $S^{A,B_{1},...,B_{n}}$ is a type constructor covariant in
$A$ and contravariant in $B_{1}$, ..., $B_{n}$ (or vice versa),
and $Z_{1}$, ..., $Z_{n}$ are fixed types. 

\begin{comment}
this is part two of chapter seven in part one we have looked at several
examples of Mona\textsf{'}s and we found that generalizing the monad type signature
led to very different types there are different properties of containers
some of them expressed iteration other expressed failures recovery
from flavors evaluation strategies and soon in this part I will talk
in more detail about the laws and structure of these containers of
these types and we will see why is it that flatmap type signature
which is kind of a little strange and bizarre maybe at first sight
gives rise to such a generalization we'll see that the properties
of Mona\textsf{'}s are completely logically the derived from the properties
that the computations must have so let us think back to our examples
of Thunder block programs and let\textsf{'}s for simplicity consider that we
are talking about the container such as list where the functor block
let\textsf{'}s say of this kind expresses iteration over a list so we have
been here for example in nested iteration of some sort what will be
the properties of counter block programs that we expect to have the
main intuition is that when we write a line like this with the left
arrow which is in scala called a generator we expect that in the later
lines the value of x will go over items that are held in the container
see this is our main intuition so in particular we expect that if
we first say that X goes over items in container 1 and then we make
some transformation of that X let\textsf{'}s say using a function f then we
expect and then we continue with that in some other way with some
other generator we expect that the result will be the same as if we
first transformed container 1 and replaced all its items by the transformed
items by the f of X and then continued so so in other words we expect
that this code and whatever follows it should be equivalent to this
code and whatever follows it now if you remember the main intuition
behind how to interpret the generator lines each generator line together
with all the code that follows it defines a new container which would
be a result of some flat map call so let\textsf{'}s write down what that flat
map call is for the left it has count 1 flat map and then X goes to
cone 2 of f of X because Y is just a replacement of f of X on the
right hand side we first apply a map on the cont 1 and then we do
a flat map with y going to constitute of Y so if the code on the left
is to be equal to the code on the right in all situations it means
that we have this code should produce the same result as this code
so that is an equation that we expect flat map to satisfy so flat
map together with map must satisfy this equation the same situation
should happen if we first have some generator and then we perform
the same thing so in this example we first manipulated items and then
we did another generator here we first do some generator and then
we manipulate items it should be the same result that gives a rise
to this law which is that first container flat map of this should
be the same as the first container flat map of all this so that\textsf{'}s
the second law that we expect to hold it is necessary to do these
two laws because the way that the lines are translated into flat maps
is linear so it\textsf{'}s the first line and then the second line and the
third line and so if you have this construction replaced by this after
a generator and that\textsf{'}s a different code then if it were before January
this these things cannot be interchanged especially since this could
depend on X and so X is only available after this line so we could
not possibly put this line after these two and so most in most cases
but you cannot interchange lines in a functor block without changing
the results so that\textsf{'}s why we needed to have these two situations when
the replacement is preceded by a generator and when the replacement
is followed by a generator finally we expect another thing which is
that we expect to be able to refactor programs so a for yield blog
or a functor block as I call it returns a container value and this
container value could be put on the right-hand side of another for
yield blocks generator line we expect that this should not change
the meaning if we in line caught the contents of that four yield block
so here\textsf{'}s an example on the Left we have a free Oh block with three
generator lines on the right we put these two first lines into a four
yield of their own the result of that four yield is a another container
and we put that container in the right hand side of a generator line
and we continue like this so this is I just call this YY for simplicity
yes it\textsf{'}s exactly the same as this Y except the two lines here are
in line here they're hearing a separate for um block so we expect
this to always give the same result as that if that were not true
would be very hard to reason about such programs if you in line things
in programs and have gives you different results that\textsf{'}s a bug usually
it would be very hard to find languages where this happens are broken
and shouldn't be used if they have better choices so now we therefore
require that this law should hold so if you in line things then results
should be the same and if you express this in code then you see here
on the left you have called a flat map of P and then flat map of contour
on the right you have firstly have a con flat map of P which gives
you this and then you get flat map of come to so you see this second
flat map is inside the first flat map as it should be in the filter
block but the in this case it\textsf{'}s not inside as you first do the flat
map is a separate for you block and then we do another regenerating
life so in this way we have these three laws now if we write these
laws in this way that\textsf{'}s in principle sufficient to check those laws
for specific examples I just need to write code and transform code
we would like to be able to reason about these laws in a more concise
and elegant way we like to understand what these laws mean in a different
way so that we can conceptualize them because right now it\textsf{'}s just
some complicated chunk of code should be able to give the same result
as some another complicated chunk of code and it\textsf{'}s not I'm just not
clear what will it mean it\textsf{'}s not easy to understand these laws like
this so we're going to rewrite them in an equivalent way using a different
notation so first of all we introduce notation which is flm which
is kind of flat map with arguments reversed similar to what we did
with f map where we put in a function argument first and then the
monad type argument second whereas the flat map usually as this argument
first in this argument second so for convenience we do that and that
turns out to be much much similar to F map it\textsf{'}s a kind of lifting
so you lift this kind of function into this kind of function we will
exploit very much this property and therefore FLM is a more convenient
type signature for reasoning about the properties over semi monad
I remind you that a semi monad is a monad without the pure method
so semi monads just have flat map and you can define flattened in
terms of flat map but that\textsf{'}s it we do not have the pure method in
semi monads and a full monads additionally must have the pure method
so right now we start with semi monads so in other words we only talk
about flat map and its properties which are summarized here later
we will talk about pure and its properties so in what follows I will
fix the factor s the semi Morland and I will not explicitly put that
s as a type parameter anywhere so we F map will be with respect to
the factor s and F Alam will be with respect to the founder s so let\textsf{'}s
write down these three laws in this notation and if you look at this
I'm just going to translate this code into that notation you'll see
it becomes more concise and then we look at types and we will be able
to reason about it much easier so for example this is a composition
of two functions we first apply f when we applied comes to so this
is a flat map of a composition whereas here it\textsf{'}s a map followed by
flat map so it\textsf{'}s a composition of map and flatmap sir here\textsf{'}s this
law flat map of a composition is equal to a composition of map and
flatmap so this is now I wrote out the types of the functions F and
G and here\textsf{'}s a type diagram for this equation I remind you that the
type diagrams are just a fancy way of writing equations more verbally
with more detail and more visually so here the left-hand side is a
function on the right-hand side of the function and these functions
go from here to here so si is the initial type as C is the final type
and the first function is a composition of F map and f LM and the
second function is a nephilim over composition so if you go from here
to here whether you go under upper route or the lower route you get
the equal results that is the meaning of this diagram in mathematics
this is called a commutative diagram meaning that this path and these
paths can be commuted they can be in touch with no changes in results
I will not call them commutative diagram because it\textsf{'}s to me this is
confusing what is what are we committing all the time it\textsf{'}s just a
type diagram for us that shows us very clearly what the types are
and what the functions are between each pair of types and what are
the intermediate types when we do a composition of functions and there\textsf{'}s
some intermediate result and I remind you also that my notation is
such that this composition goes from left to right so we first apply
this function to some value and then to forget the result this is
this intermediate result of this type and when we applied that function
to that guzol we get the final result so in this way it\textsf{'}s easier to
read the type diagrams so they follow the same order first F map Jennifer
land from Steph map then f LM in many mathematics books this notation
is used in other books it\textsf{'}s used the opposite way where you first
apply the function on the right and let me apply the function at the
left of the composition now I write now I feel that this not convention
is more visual there of course completely equivalent in terms of what
you can compute with those notations and in terms of how easy it is
to compute but this is a little more visual first you do this then
we do that in Scala you have the operation called end then which is
exactly the symbol that I'm using and also you have the operation
called compose on functions which is in the opposite order so it\textsf{'}s
up to you what you want to use in star alright so now I have rewritten
all these three laws in terms of this short notation now this here
for example is flat map followed by map is equal to flat map of a
map sorry of constitute followed by map so it is flat map followed
by map is far or composition or something followed by a new app and
the last one is flat map of something followed by flat map is flat
map followed by flat map so that\textsf{'}s flat my about something called
by flat map is flat map followed by flat map and so these are the
types so all these types go basically from si to SB 2 s C where a
B and C are arbitrary types and then you get the equations by either
going the upper route or going a lower route I also wrote the names
of these laws which are just for illustration purposes and to kind
of give you a way of remembering these laws the first two laws are
naturality so what does it mean naturality well naturality means that
there\textsf{'}s a natural transformation going on somewhere between the two
factors and in terms of equation a naturality law means that you have
F map maybe on the left hand side or on the right hand side and you
pull it out of that side and put it on the other side for example
here F is f is under FL m and here F is before phones are pulled out
the F out of fom but now I have to use EFT map on it after I pull
it out so that\textsf{'}s a typical thing for nationality you have a function
that you pull out and then sometimes we use F map on it after you
pull down sometimes before so here\textsf{'}s another naturality so why is
it naturally an a well it\textsf{'}s because the function f so that pull out
transforms the type a into B and here the function G that I pull out
says forms a Type B into C and so flat map it goes always a to s of
B it has to type Traverse a and B and the naturality should be in
both of these type parameters so flatmap can be seen as a natural
transformation in two ways in both of these parameters and so that\textsf{'}s
why we have two naturality laws the third law is associative 'ti and
it\textsf{'}s not obvious why that is cold like that and we will see that much
easier in later Oregon this tutorial but basically if you just look
at this equation you see this is a kind of a law for composition of
flat maps what happens when you compose two flat maps you can put
one of the flat maps inside it\textsf{'}s the same result so now this is much
better than the previous formulation with code it is much shorter
and you see the types goats always from a satyr as beta SC but still
these laws are kind of complicated so there\textsf{'}s this F map here you
have to remember there\textsf{'}s no F map here this is a bit a bit complicated
so let\textsf{'}s find out if there is a better and shorter formulation of
these laws and remember what we did in the previous chapter when we
talked about the filter rules we found a better formulation in that
we factored out the flat that the F map out of some function we got
an easier function which we called deflate back then so let\textsf{'}s do the
same thing here this functionally called flatten which I denote in
the short notation as f TM and this function is standard in Scala
understand the library is called flatten which is basically flat map
on identity if you consider identity function of type as a to SMA
then you can imagine that SAS is some other type C and so basically
you have a function from C to sa you can do a flat map on it and you
get a function from s ce2 s a and C is s to a so I put that brand
on here and the result is a function from s of s of a to SMA and you
can also define flat map out of flatten by prepending it with with
a map with map so this is a diagram it shows their relationship so
if you have an essay you can s map it with a function it was B you
get an SS B then you flatten it to s B and that\textsf{'}s the same as a flat
map so that\textsf{'}s a well-known equivalence but flat map is basically a
map followed by flatten and that\textsf{'}s a scholar convention for naming
this function sir that flat map is basically flat a flatten that is
applied to a result of a map and this is the type diagram that shows
how that works so that the map from a to s be will replace this a
by s beat the result will be s of s would be and then you flatten
went back to SP so just like we found in the previous chapter on filterable
it turns out that this function flatten has fewer laws than flat map
it has only two laws its type signature is also simpler it has fewer
type parameters and it\textsf{'}s a shorter type signature so it turns out
that this is a easiest way to reason about semi monent laws that is
to consider flatten not to consider flat map to your flat instead
so what are the two laws of flat the first law turns out to be this
which is double F map of a function f and then flatten gives you a
flattened followed by an F map of function f so that\textsf{'}s naturally so
naturality here is much easier it\textsf{'}s just commuting flattened with
a function so here you have that function on the left hand side the
flattened here\textsf{'}s on the right hand side of flatten and they need an
extra F map on that it\textsf{'}s important to have two F maps here on the
one here you kind of just replace this with an arbitrary function
G for example this you cannot replace this with an arbitrary G and
have an F map of G in the red right on the left hand side here that
law does not hold it\textsf{'}s it\textsf{'}s mean it\textsf{'}s incorrect so the type diagram
for this law is like this so you start with s of SMA you do a double
flat map sorry you do a double map double F map of a function f which
goes a to b so then you get a survey survey into SMS of B after the
double map then you flatten that into s B or you directly flatten
first a survey survey into a survey and then you just have a single
AF map of A to B and you get a survey to assume D so those must be
identically equal now just one more comment about notation I'm using
here the short notation where I say for example F map F with a space
F map space F I don't right parenthesis here I do that for functions
of one argument and when when things are short here I don't I say
F map of F map of F because this is not short this is a longer expression
and be harder to read that\textsf{'}s my notation so it\textsf{'}s exactly equivalent
to putting parentheses around this F around this F here it\textsf{'}s shorter
to read this so this is similar to the mathematical notation where
you write cosine of X without parentheses you read cosine X cosine
2x sometimes without parentheses just shorter the same thing the second
law now looks like this F map of flattened followed by flatten is
flatten followed by flapping except that there is first flatten is
a different type parameter as it\textsf{'}s applied to a survey survey so let\textsf{'}s
look at the type diagram for this law both sides of this law applied
to a value of this type which is kind of ridiculous but that\textsf{'}s what
it is it\textsf{'}s a triple application of the factor s and you can flatten
it into a single application and you can flatten it in two ways first
the upper path in this diagram you f map of flatten which means that
you flatten this into si and you f map the result so that you get
flattened as a resume and then you flatten again the second way of
flattening is to pretend that this type is some B so this is just
a service of B you flatten that you get s of B now B is s of a but
you just apply the same code for flatten to a different type parameter
parameter s of a instead of parameter a and then you get again a service
of a and then they flatten it again so the result must be the same
of going up or going down now it\textsf{'}s important that all so that we flatten
twice these two are not going to be equal after the first step only
after the second step they're going to because we'll see that on an
example so why is this called associativity well this is a little
easier to understand now why so look at this triple-s implication
we can flatten it first by flattening the inner pair of s and then
flattening the result or we can flatten it by first fighting the outer
pair of s which is going this way and then flattening the result so
this is like a subjectivity first we do we have three things we can
first group two of them together and then group the result and the
other thing together and that\textsf{'}s two ways of doing that and so in mathematics
and social division law is usually of that kind you have three things
you can pair the first to combine them and you get the result and
you can prepare that with a third one or you pair the last two combine
them get the result and pair with the first one and that if if the
two results are the same regardless of would you pair first that\textsf{'}s
a social tippity law that\textsf{'}s the mathematical intuition so now it\textsf{'}s
a little easier to see why this is called associativity but the equation
for this law does not look like a social ticket it doesn't look like
there are three things that we're appearing together so that still
maybe not great we'll see a different formulation of the law where
it is completely obvious that that\textsf{'}s associative 'ti and it looks
like a socially routine but now we already see that it\textsf{'}s getting there
with this pairing of the functor layers now a little aside here we
found that the functions F alone flat map and flatten are equivalent
does it mean equivalent if you have one of them you can define the
other if you have the other you have can define the first one but
not only that but these definitions are equivalent if you take the
first if you somebody gives you a definition of the first you define
a second one and then you define again the first one through that
second one you should get again the same function that you were given
so that\textsf{'}s full equivalence and we have seen this kind of equivalence
like this in Chapter six when we looked at deflate and F map opt they
were equivalent in a similar way deflate was F map of identity F map
opt was F map followed by the flight it\textsf{'}s exactly the same thing here
with flatten and F and flat map so naturally I asked myself is there
some general pattern where this kind of situation happens in two functions
are equivalent yes there is it better it\textsf{'}s a little difficult to see
maybe right away but there is an obvious pattern in the end so here\textsf{'}s
the pattern suppose you have a natural transformation between two
functors F of G of a and F of a that\textsf{'}s how it must be sorry this is
a complexity here F of G of a goes to F of a that\textsf{'}s the entire complexity
that needs to be understood before you go through this this example
so you assume the two factors F and G and there\textsf{'}s a natural transformation
of this kind so {[}Music{]} TR is the transformation of this kind
now we define F TR which is this type signature some sounds familiar
right it\textsf{'}s not quite so it\textsf{'}s not quite it\textsf{'}s a different filter here
than here so it\textsf{'}s not the flat now but it\textsf{'}s quite similar that\textsf{'}s the
pattern so how do we define this f TR we first do an F map of F so
f is this when we do an F map we get an F so we start with F of a
we do have if map of F we get an F of G of B and then we apply the
transformation TR which goes from F of G of B to F of B and then that\textsf{'}s
how we get F of B now it follows obviously that this TR is f TR of
identity so if you put identity here instead of F then F map of identity
is again identity so it\textsf{'}s identity followed by TR that\textsf{'}s TR so that
kind of thing is immediate what is less obvious is that TR and f TR
are equivalent not just TR can be defined from FDR but FDR is defined
from TR and these two definitions are equivalent here\textsf{'}s the type diagram
we start from F a we do an F map with a function f from A to G B we
get an F G B and we transform that with TR into FB we assume that
this is given this this is a transformation that is available and
the other way is to do F G R of F and that should be the same so that\textsf{'}s
a definition you can see that as a definition of F G are given TR
or a definition of TR even f TR because you can put identity here
and there are two interesting things that follow in this construction
first interesting thing is that there is an automatic law for FDR
that follows from the definition of FDR through TR so the naturality
in a for FDR follows automatically and here\textsf{'}s how it falls with an
F map of G and FDR then you substitute the definition of FDR so then
we get this then you have the F map composition law so you get this
and then this is again a definition of fgr in terms of TR so you give
this so that is a natural T law that pulls out G out of f TR and puts
it in light left-hand side with an F map and this law automatically
follows from the definition of FDR\textsf{'}s root here and that\textsf{'}s why TR has
100 fewer than FDR that\textsf{'}s why we had flattened has two laws and flatmap
has three laws same thing was with deflate and f map opted deflate
has fewer laws one fewer laws then F my pooped for this reason because
one law automatically follows from the definition and the second funny
thing that follows is that they're always accruing these functions
they don't this proof we can do a proof of their equivalents and the
proof is for any F and G so this will be the same proof for deflate
and I've mapped as for F a lemon of T M I believe in Chapter six I
did not go through this proof I just told you that deflate can be
defined from a flap opt and asthma pooped can be defined from the
fly but I did not prove that these definitions are equivalent and
it could be that they are not equivalent without proof we don't know
that and the way that they couldn't be not equivalent is that somebody
gives you a t flight you define a left may opt out of it then you
define a deflate out of sorry sorry it\textsf{'}s here somebody gives you a
deflate you define define f map opt out of it and then you use that
F map opt define another D flight here and that second deflate could
be different from the first one and if that were so these definitions
are not equivalent would be not equal so this is not so these definitions
are always equal so how do you do that well the equivalents must be
demonstrated into both directions so in one direction is obvious because
it\textsf{'}s just identity you substitute identity and that gives you the
same function back in the other direction is less obvious you start
with an arbitrary FTR that already satisfies this law the naturality
in a look at the type signature and fti it has two type parameters
a and B so it has naturally low in a and that relative low and B so
what happens when you first transform a that\textsf{'}s not reality in a what
happens when you transform B that\textsf{'}s not relevant B so you have to
assume that you're given some FTR with this type signature that already
satisfies the naturality in a if that so you can define TR of it by
substituting an identity and then you define again another of TR by
using that TR you just defined so you want to verify that that FG
r is equal to your previous one that was given to you here how do
you fara Phi this well you take F map F followed by TR substitute
the definition of TR then you have your natural it in low right here
what you use you get f TR of G followed by evidence and that\textsf{'}s FD
R of F followed by identity identity disappears even FD R of F so
that\textsf{'}s why you're very that\textsf{'}s how you verify the squiggles so we have
shown at once with one proof we have shown equivalence of deflating
as my popped and equivalence of flatten and flat map because they're
just particular case of the same construction with different F and
G if you look at the type signatures then it\textsf{'}s clear clearly self
now let\textsf{'}s actually derive the laws for flat I have shown you the laws
I have not derived them showing you these two laws per flat and I
have not derived them yet so I will derive them now to make the derivation
quicker I will have this notation instead of F map I'll put an up
arrow now the up arrow reminds you that it\textsf{'}s lifted into the functor
so instead of Q a function of A to B you have a lifted Q which is
a function from s a to s B so using this notation I'm just going to
write shorter acquaintance other than that it\textsf{'}s just F map and same
properties flat map is defined like this let\textsf{'}s substitute that into
the three laws of flat map so the first law of flat map is like this
second was like mysteries like this now I'm not going to write any
types in these equations because we know that the types match and
everything we substitute has matching types so we don't need to check
that every time the types match so for example here I was writing
these equations I wrote types in certain places so f is it to be for
example I wrote types in full in these diagrams so once we have verified
that the types match we don't need to keep writing these types we
know they match so f is a to B let\textsf{'}s just not right a to be here anymore
f is a to B G cannot be just B to C because it\textsf{'}s under flat map so
G must be some b-2s C right so where is this law here G must be of
type B 2 SC otherwise flat map doesn't have the right type of its
argument so that is check to check this once we don't have to keep
writing these types and it will be just shorter if we don't we believe
now that types are correct initially and if they're correct initially
whatever we substitute the types are continuing going to continue
to be correct and so that\textsf{'}s just going to save us time reading equations
but in principle you should understand that these are specific types
of example F here must be a to B and G here must be of type B going
to SC otherwise it just doesn't work and similarly here so here this
is lifted G so this is some s B 2 SC already and because of that F
must be going to SB from something from a let\textsf{'}s say a to SB so all
these are implicitly the same as here and so I'm not going to repeat
the types ok first law we take this we substitute a definition of
F L M into both sides on the left it will be FG lifted followed by
flatten on the right will be F lifted G lifted followed by flatten
clearly this is always holding because of lifting is an F map and
that preserves function composition second law substitute the definition
of f LM and we have this so now if you think about the functional
composition here then the lifting which is F map will preserve function
compositions are all being F lifted followed by G double lifted and
there was enough lifted on the left here as well so we can get rid
of this F lifted because the SLO should hold for any F so we could
for example substitute F equals identity into both sides and I will
just F will just disappear I've lived in his disappearance the result
will be this G double lifted followed by flatten is flat and followed
by G lifted so that is the naturality law for flatten which we had
here F method of G f SS 'td : back flatten is flat and followed by
s waisted so that\textsf{'}s naturality so the first law was holding automatically
that\textsf{'}s the same thing that we found in general construction one fewer
laws for fun the third law now the associativity law again we substitute
the definition and we get this so flatten is this lifted followed
by flat so this would be this F lifted G double lifted flatten lifted
followed by slide on the right hand side will be F lifted flattened
G lifted flattened so again we we find we can use the neutrality here
so flatten followed by G lifted is here we replace it by this and
so we get F lifted G double lift it flatten flatten and flip the G
double if that is on the left it\textsf{'}s a common factor we can just omit
it or substitute both F and G identity for simplicity but it\textsf{'}s clear
why we can do this it\textsf{'}s just a common factor on the two sides of the
equation and the result will be flattened lifted followed by flattened
equals flatten followed by flatten so that\textsf{'}s the associativity law
so that\textsf{'}s how we can derive this law and because of this general construction
are explained here once you start with flatten in the define flat
map then the extra law will be holding automatically so in it\textsf{'}s very
similar way we're also going to we can also derive the laws backs
if you assume that somebody gives you a flatten that satisfies these
two laws then we can derive the laws for fom which is basically the
same calculation except you see here the F and G are arbitrating so
you can have to start from here and go back to this in the same way
these are all equations and they are equal in both both directions
we have been careful and we do not lose generality so in this way
I have shown that flatten laws are equivalent to flat map laws but
flatten has a simpler type signature and the fewest laws so when we
check laws for monads and semicolons I will use flatten laws rather
than flat map it\textsf{'}s quicker even though flatten has this complicated
Esteves of s of any type in its laws but even that complication is
offset by the simplicity in in other places and there are fewer laws
naturality is usually easy to check and the reason is that if the
code of the function is pure it has no side effects and it is fully
parametric so that it has no specific reference to a type other than
the tag parameter so their only arguments that are type parameters
and the only operations we use are those that are compatible with
arbitrary types as type parameters if so it said what I call it fully
metric code and then there is a periodicity theorem which says that
if you have a function of this type with a tag parameter a and F and
G being factors then this function code if this functions code is
fully parametric and pure then this function implements of natural
transformation what\textsf{'}s the theorem I'm not going to prove that here
but that\textsf{'}s something we will use for basically not checking any naturality
if it\textsf{'}s obvious that the functions code is fully parametric has no
side effects and does not refer to any specific type so for example
doesn't match on type rather a being integer and then does something
special none of that is permitted in fully parametric code checking
associativity means a lot more work for monads it\textsf{'}s a complicated
law and that\textsf{'}s not easy to check so I will show in detail how to do
that on a number of examples as a as a remark so I've been talking
about silly monads the catch library has a flat map typeclass which
has a flatten method defined by a flat map but that type was in in
the cache library also has another method called tail rec M which
is the recursive modown method and that method is out of place at
this point it\textsf{'}s it\textsf{'}s different more complicated method and not all
walnuts have that and I'm not going to use the flat map typeclass
from the cats library because of this but I can't define it without
defining this extra method that\textsf{'}s really out of place I believe that
the scholars new library has also type glass like this with no such
extra methods so good of you scholars the scholars in star classes
but actually I will just define my own standing water plant class
it\textsf{'}s just not hard and not a lot of work so now let\textsf{'}s go and check
the code to see how we verify of that laws hold for the standard walnut
so go through the list of standard units will implement the flatten
for each of these the code implementing flat o is going to be fully
parametric type parameters so there\textsf{'}s only one type parameter in the
flatten type signature its SOS so very going to isolate and so we're
not going to check naturality it\textsf{'}s it\textsf{'}s going to be automatic but
the social DVD has to be checked so after we check all this I will
show you why certain examples are not fully correct they're incorrect
implementations of flatten and that\textsf{'}s that would be useful for you
to understand that these laws actually are not arbitrate they express
what it means for Lunada to do the computation we wanted to do to
remind zero started all the way from what we want these programs to
be like and these programs need to have certain properties if they
don't have these properties which can happen if we don't implement
the functions correctly mr. in cases then the programs written using
those types will have very difficult to find bugs and that\textsf{'}s a very
bad situation that we can avoid so let\textsf{'}s go into the code now we start
with the option bow nod and the option monad has the flatten function
so I'm just going to be writing out Scala code for all of this this
is an obvious implementation of flat if the option is empty we have
to return empty there\textsf{'}s nothing else for us to return if it\textsf{'}s not
empty then there\textsf{'}s an option inside we return that optional as there
is not we also need a functor instance for this because we are going
to use F map to check the law so the functor instance of course Scala
library has flattened and map defined already on the option type but
I want to write out this code explicitly so that we can check the
law explicitly so there\textsf{'}s this code if it\textsf{'}s not then it\textsf{'}s not if it\textsf{'}s
something we substitute the function instead of the value and curl
F optional is an action of all witnesses of type a so I should not
remain this into a perhaps clarity alright so now that we have this
let\textsf{'}s start the verifying the law how do we verify the law the law
here\textsf{'}s well morality we don't need to verify we verified this law
associativity to verify this law we need to compute the left-hand
side and the right-hand side and we need to compute them symbolically
in other words we write code for the function that computes this we
write code for the punch it appears that compare these two pieces
of code and show that they are identical code so this is not right
running a test with numbers sorry you know numerical check or arbitrary
strings random strangers anything like this this is actual symbolic
proof that these are identical functions symbolically and in order
to go through that proof we need to compute for example this the F
map of flatten as symbolic code then we will compute the as map of
flattened followed by flatten again as symbolic codes what\textsf{'}s go and
see how that works so first let\textsf{'}s compute F map of flatten so we have
asked my up here we can flatten here let\textsf{'}s combine them compose these
functions so how do we do that well we say we first write the code
of F map which is this let me write that in a car in a comment perhaps
so that it\textsf{'}s easy to see why that is like that so first I start with
this code this is a code of ethnic now instead of a function f I needed
to put FTM now what does f TM f TM is this code is so f TN of a is
a match of this so that is the code that I'd see here so that\textsf{'}s how
it is that\textsf{'}s how it was the same code except I write X here and sort
of a so all right so now that\textsf{'}s less less less code so now let\textsf{'}s compute
this thing which is the right-hand side of the associativity law how
do we compute that we write the code of FGM applied to the type parameter
F of 8 well that is not going to change the code of the code the vestian
is generic it works for any age so we don't need to change the code
before we need to change is to change the type parameter so this is
going to be just instead of optional a this is going to be optional
optional a and so there\textsf{'}s going to be some different type the code
remains the same we can put X instead of oh it\textsf{'}s just the same code
okay so this is this is flattened now we need to apply another flattened
to the result of this now the result of this has two pieces there
is this result and there is this result so let\textsf{'}s apply this a flattened
to each of the cases so this is going to be flattened of none this
is going to be flattened of X so now we need to substitute the definition
of flatten into here see what we're doing here is we pretend that
we are the compiler and we symbolically write code that the program
are specified by in lining functions we're just substituting definitions
of functions where they are used so flatten is like this and so none
goes to none and some of away he goes - away therefore none goes to
none so this is none FTN of none is none an FTM of X is so let\textsf{'}s call
as X so this is going to be X match and then this code so that\textsf{'}s why
ft and of X is this so that\textsf{'}s why we write that code so now we have
FGM followed by left in the same way we compute ft/s map of FTM followed
by f teen where none is still none and then I still have this we have
this code so now we compare the code for this and the code for this
and we see it\textsf{'}s exactly the same code the types are the same but leave
the types must be the same because that\textsf{'}s one team but the code is
actually same if we were named variables you know I renamed some variables
X instead of Kawai whatever that doesn't change the code so after
in naming variables we have exactly the same code therefore the law
codes so that\textsf{'}s how we check the law for the option not well so far
we checked only semi mana so we check the associativity the next example
is either gonna which is defined like this is some type Z which is
fixed and the type A and the flatten has this type signature so in
a Scala syntax flatten would have this type signature either of Z
either of Z equal to either now we could do exactly the same thing
we will will write down flatten write down F map then compute symbolically
a flap of flatten by substituting in computing symbolically this substituting
in computing that and compare the code we got exactly the same code
but now you're free to look at this computation and follow it in an
example code but actually for either there is an easier way out you
can check associativity with very little work and the reason is that
the type signature of F map and F we have slather followed by flower
and of this the type signatures actually misses one mistake it\textsf{'}s miss
Z plus Z plus Z was going to zero said right so Z plus a is just my
short type notation for either of Z a now it turns out if you look
at the curly Howard correspondence and try to give derive the implementation
of a function of this type it turns out that this type signature only
has one implementation it has only one implementation which which
is because either you have a Z in one of these positions in one of
these parts of the disjunctions or you have a name have a Z there\textsf{'}s
only one thing you can return you can we must return the left part
of the disjunction with a Z until heavenly you must return the right
part of the disjunction with a knife there\textsf{'}s nothing you can do other
than that so there\textsf{'}s only one implementation of a function of this
type as long as you use peer functions that are fully parametric of
course and that\textsf{'}s where curry how it responds is valid only for those
functions so therefore there must be exactly the same code for this
function and for this function we don't have to prove that they are
equivalent there\textsf{'}s only one way to implement anything here so this
one that can be implemented completely automatically from the type
signature and no law needs to be checked in terms of associativity
law doesn't need to be checked because there\textsf{'}s only one implementation
so that\textsf{'}s a shortcut if you don't want to take this shortcut look
at this code is done exactly the same way as we did for the option
so I will not go into this huge detail the next example is the list
monad now the list monad has a kind of a more difficult definition
because it concatenates lists so we know in the Scala standard library
the list flatten method is defined which just in cabinets nested lists
into one nested list so it works like this you have you have a list
of lists like this so all the nested lists are just concatenated together
and one flat list is returned that\textsf{'}s how flatten works so let\textsf{'}s now
show symbolically that the flatten defined in this way satisfies associative
so we're just going to to do that so how did you probably show that
I'm not going to write code it\textsf{'}s possible certainly to prove this
using code but it\textsf{'}s much more cumbersome and it doesn't really give
us a lot of new insight gives us it\textsf{'}s obvious enough how it works
so here it is so f map of flattened would take a list of lists of
lists of it so here\textsf{'}s a list of lists of wisdom I have X 1 1 X 1 2
1 1 1 1 y 1 2 and so on so this is the first nested thing this is
the second mr.thang another more maybe of those and what it does is
that it flattens the inner ones because we're were lifting the flatten
which means that the outer layer remains the same but we're operating
on the inner layer so we're gluing together these and the result would
be a list like this and then when we flatten that we get the same
result as when we first flattened the outer layers and then flatten
the inner layers so that is obvious because flattening basically says
if you have a nested list of any depths you don't care about the depths
you just erase all the brackets in between and just erase all of this
and you get one big list with all the elements that you ever have
in this order together and of course this doesn't depend on the order
in which you erase brackets and that\textsf{'}s why associativity holds so
we can first flatten the inner two nested lists or we can flatten
first the other two nested lists are going to be the same thing so
flattened as applied to the type parameter list way means that the
inner list of a remains untouched we just flatten the outer layers
so we have as a result a list a flat list of all the inner lists the
result is going to be the same so here I have some numerical tests
to illustrate this so I made this list of lists of lists and if I
flattened it first like this I get this and I flatten flatten I get
this if I first a map flatten then I have this list which is first
concatenated in earlier and then I can catenate it again so here I
first and get immediately outer layers and the inner layers inner
list remained unchanged so this illustrates how the list monad works
the next example is the writer movement now the writer monad is this
type or W must be something good so let me say that explicitly that
W must be a semigroup and then flatten is defined like this so we
have to pull a double on a tuple W and either these are the two WS
and we just combine them using the semigroup operation so this is
the second group operation and I'm using Katz syntax with seven OOP
so let\textsf{'}s check that the laws of a social Ava\textsf{'}s associativity works
here we will not be able to use the correspondence here because this
does not follow from the types the second group operation can be arbitrary
it doesn't follow from the types must be given so F map is obvious
we just don't touch W we transform the first element of the tuple
so we compute them flattened of flatten symbolically and that is we
need to first flatten so that first flattening will give us combining
W 2 and W 3 and the inner one untouched and then we can bind this
and the result will be that so now it\textsf{'}s the other way around first
we do the F metal flatten which will combine the inner ones and flattening
that will combine the outer ones after one with this result so we
see the code is exactly the same except for the difference in the
order in which we apply the semi group operation and so if the semi
group operation is associative which it must be if it\textsf{'}s a lawful semi
group then the code is identical it will give you identical results
so assuming that the law of serogroup holds which is a subjectivity
of a single group operation we can see that the writer Malad is associative
and the next example is the reader moment for the reader model we
can use the curl our trick in fact did I check that there\textsf{'}s only one
implementation in the easier movement I did so I use the curly Howard
library here which has this function so this is a great hard library
and the function is any of type which gives you a list of all implementations
of a given type and then I check the links of that list so if you
look at the type of this function it\textsf{'}s a sequence of functions of
this type so this is a special API that allows you to check that actually
how many implementations exist or given type and the test assert so
there\textsf{'}s only one implementation so that\textsf{'}s what we can do with a curly
Howard library automatically check how many implementations there
exist and that\textsf{'}s the same thing here so the flatten signature is like
this for the reader wouldn't and the signature for the war for the
associativity law is read a really reader of a which is this going
to read their obeyed and again there\textsf{'}s only one implementation and
so therefore it\textsf{'}s not necessary to check my hand any laws but I show
nevertheless nevertheless how to check it\textsf{'}s a little instructive so
I'm an exercise in substituting functions until arguments or you have
higher order functions as arguments so this is a bit complicated but
let me just give you this if you want to go through it you can follow
this derivation is there anything is commented let me just show you
the beginning steps so the flattened function is defined in the obvious
way basically you have a result and you need to return this function
so then you're right this function which you return it takes an argument
R and it must return a result of type a and the result of type a you
can only get by substituting r twice into the function of this type
which i called r ra to make it more visual what that type is and similarly
the f map implementation is automatic there\textsf{'}s only one way to implementing
it you must take an R because that\textsf{'}s the function you have to return
and you must return a.b the only way to return a B is to apply F to
some a the only way to get an ace to apply r8 or some art that\textsf{'}s the
only are you have and so you apply our a to that are and you apply
F to that and then we compute for example this symbolically how do
we compute that while we take FTL which is this function are going
to this except you have this now as an argument as a different type
of the code is the same it\textsf{'}s generic code so the code doesn't change
I just change the name of the variable here for more visual reference
and then you apply FTM to that so when you apply FTM to that you take
the code of FTM and substitute that function instead of this and instead
of argument of ft n so when you do that you have are going to this
function applied to R and again to R so this function applied the
first one to R will give you this and then you again apply this to
heart so let me get 3 R\textsf{'}s and in the same way you compute so you substitute
so the only the only problem here is that you need to understand what
it means to substitute a function in as an argument and the function
is given like this so you want to compute FTM of this function which
is given by an expression so you need to substitute instead of RRA
here intersubjective this expression so you do that step by step the
first application ar-ar-ar the first part is what will give this argument
art here so then you substitute the body of this function which is
our RA of our of our into our RA of our so ok let me show you that
perhaps on an example so this is FTM now instead of rrn you need to
use this this is the argument of FGM now so first we apply art to
it so you apply it to R which will give you the first argument you
need and so that means this goes away and this goes away and that\textsf{'}s
it so that\textsf{'}s how it works not to get any result so in the same way
you follow the other derivations and I'm going to skip them in the
interest of time they're straightforward and you always get this AR
AR AR AR AR AR AR as a result the next example is the statement the
statement has some deep connections with category theory which are
beyond the scope of this tutorial because for all those elegant mathematical
connections I haven't seen much or at all that any code can be written
because of knowledge of those theoretical connections so for this
reason this lack of practical application I will not talk about this
very much and also I haven't studied it extremely deeply but nevertheless
it\textsf{'}s important to understand the statement is quite special and so
in particular it well this is the type of the statement it\textsf{'}s not obvious
that this type does what it should in the part one from this tutorial
I have given some intuition behind choosing this type but nevertheless
this type is not so easy to understand so unfortunately the curry
Howard method does not work for this because there are several implementations
of the type signature of flatten and so there\textsf{'}s no way to argue that
since there is only one implementation then the law must hold so let\textsf{'}s
check the law explicitly the associativity for the state model the
flatten that we defined for the state model has this type signature
and it\textsf{'}s defined by returning this value which is a function and so
your return function it takes the value of type s and then it should
this function should return a tuple of a and s and what tuple does
it return well the only way to return anything that contains a so
to use this function somehow so we call this function on this value
of s it doesn't seem to be much else we can do the result of colony\textsf{'}s
function is a tuple of two values one is this which I denoted here
in SAS and the other is another value of S which I call this one so
now we have SAS which is this and we have an S one which is of type
s we're supposed to produce a tuple of a yes now we could call this
function on an value of s to produce a tuple and that\textsf{'}s what we do
we call this function on s1 now this is quite important that we call
it on s1 not an S as we could do all kinds of things we could call
this function on s instead of this one or we could call this function
and take just the a out of it it returns a tuple so we just take the
first part of the tuple in the second part we could substitute again
either by the S or by this one so there are different implementations
possible I just outlined four different implementations of the function
flatten or the same type signature and there are probably more implementations
so for this reason the type signature alone is not enough to fix the
implementation and it\textsf{'}s far from obvious that we need to do it like
this that this s 1 must be here but this is the intuition that we
have is that the state monad should update a state value and so each
time you call this function it can give you a new value of the state
s and you should use a new value henceforth so the intuition behind
this implementation is that once you have used the old value you get
a new state well you shouldn't use the old one anymore so whatever
you do you should use a new one here after this step you get a value
of type PS so that\textsf{'}s again a new state you should use that you should
return the new state shouldn't return the old states that you have
have been used up so that\textsf{'}s the intuition behind this implementation
but of course this intuition is not sufficient to show that this is
the correct implementation of the state monad so that\textsf{'}s what we'll
have to do now so in order to demonstrate the associativity law we
need to implement F map so I simplement it it takes an essayist and
your turns in SBS so here is what we need to do again here we return
the new state and not the old state we could presumably here return
the old state but that would not be correct now let\textsf{'}s compute the
composition of flattened and flattened so here\textsf{'}s what we do well we
need to confront this triple layering of the state model I'm gonna
type a which I denote it like this so first we apply flat into it
so I'm just pasting the code for flatten which is this and substituting
this thing in it and then you have to apply flatten to the result
now how do you apply flatten to the result or you substitute the definition
of wanton flatten of something is equal to this and then instead of
this application we put the previous code the code that was here applied
to the value s so that is now how we get the code of flatten of slapping
it remains to simplify this code a little bit so we can pull this
Val outside of the block because it doesn't depend on anything so
you can pull it easily outside let\textsf{'}s pull it outside now we don't
need the blocks and then we have this more streamlined code so we
have the first date we get it updated get the second state this one
goes into here and gets us two and finally we use this tool and return
the new state and the new value so that\textsf{'}s kind of natural given that
the statement is supposed to update previous state into a new state
and return a new state so now let\textsf{'}s see if we got the same code by
looking up the other side of the associative a table so I remind you
what that law is is that flatten flatten is equal to lifted flatten
followed by flatten so we computed this part so for fighting fighting
now we need to compute this so first we can put the lifting of flatten
so how do we compute that we put the definition of flat inside of
F map so f map of this function we substitute so it\textsf{'}s the same way
we substitute and we get this code so this is the code of flattened
substituted into the code of F now now this is not easy to understand
what I'm going to look at this right now and try to simplify it or
just going to continue and simplify at the end so now we take this
code and we apply flatten to that so the result is going to be less
we we take the code of flatten which is this and instead of so let\textsf{'}s
look at called a flatten again just quickly it is this code so the
argument of Latin is dysfunction that is applied so now the argument
of flatten is this lifted flatten so first we applied the lifted flat
and then we apply flatten so the argument of flatten is this so therefore
it\textsf{'}s like this so we need to apply it like this so now let\textsf{'}s substitute
the definition so we substitute this code into here we get this I
encourage you to go through this yourself because it\textsf{'}s hard to show
exactly what happens but I'm basically just substituting a definition
of this function which is here into here and applying it to the arguments
so the first argument is this and the second argument is yes yes so
the result is the scope now we need to simplify so how do we simplify
I will pull out again we can pull out this and out of the block and
then we notice that we have this function essayist that is being applied
to this one and it\textsf{'}s defined like this so I renamed it the first three
but this is just the argument of this function I say yes so when we
apply a sinister s1 it means that here we get s 1 instead of s 3 so
that\textsf{'}s just replace as 3 by s 1 in this block and in line it so the
result will be this so now you see it\textsf{'}s exactly the same code as we
had when we did the first part is this good so after identical transformations
identical transformations are just inlining definitions of functions
into the code and substituting arguments into functions as if we are
evaluating but we're evaluating some bulletin so the result is another
piece of code that\textsf{'}s what what I mean by evaluating symbolically so
this shows that the subjectivity law holds for this implementation
of the statement and in fact if we had any other implementation for
example if we had here a second instead of s 1 then this law would
fail there\textsf{'}s only one implementation of the statement that satisfies
the laws using connections to category theory that I was talking about
you could show that laws are satisfied much easier but the price for
that is a huge amount of extra effort in understanding the so called
at junctions or adjoint factors and those are quite technical and
not easy to imagine what they mean so I rather not go there right
now and so we have actually valuable experience reasoning about code
and that\textsf{'}s good enough for now the next example is a continuation
when I which is this type flatten would have this intimidating time
signature well so actually again unfortunately we can't use the Curie
Harvard correspondence because lots of implementations the correct
hard very hard library returns ten implementations of fat map and
56 implementations of the type that is certainly flat not flattened
and 56 implementations are flattened of flat type services can't count
called triple layering of the Monad on top of the typing so we can't
use that argument unfortunately so let\textsf{'}s bite the bullet and unlike
we did in the reader model where we could now if we actually have
similar arguments with a bit of more complicated function types so
how do we define flatten for the continuation monad well it\textsf{'}s like
this so a continuation is this type and if you have that type signature
that was written over there then you need to return a function of
this type but you're given a function of much more complicated type
so let\textsf{'}s actually write I'll just type maybe for reference so now
CCA is continuation of continuation of a CCA is this and were given
that CC is as you see is a function which has an argument of this
type so we need to give that function so that CCA in order to get
an R so once we do that basically that\textsf{'}s what we need so we're given
a tour which is this argument we need to return R so the only way
to return or is to call CC on this function how do we get this function
I'll just write it saying that it takes this which is a see a continuation
of it and returns R so how do you return R if you are given this or
you call this on it you are and you have a tour so we call that on
a tour and that\textsf{'}s the function that we pass an argument to see see
that\textsf{'}s how we implement the flatten for the continuation Mona anything
bought clear actually once you look at this code it\textsf{'}s very convoluted
there all these functions that you create that are returning something
it\textsf{'}s unclear what this old us but that\textsf{'}s kind of important just now
F map for this mother is actually somewhat easier it\textsf{'}s just a factor
so we need to wrap this function under this it\textsf{'}s a factor because
the type parameter a is behind two layers of function arguments and
so it is in a covariant position so this this entire parentheses is
an in a contravariant position because it\textsf{'}s behind the mirror and
then a is behind another arrow within that so them a is covariant
when wanting a factor for that is always possible and that\textsf{'}s what
we do here so we have a function f going from A to B we have a continuation
from a winter eternal continuation from B so that\textsf{'}s a function taking
a be R which is a type B to R fucking right down from this to this
so how do we do that so we get a br we need to return or we're given
this which is ca we call CA on the function a to R so how do we get
a function a to R we take an A so we write those functions to ourselves
we take an am or returning our so how do we turn our we call BR on
a B when B is obtained by calling ethylene so that\textsf{'}s another exercise
in juggling around functions and their arguments with higher-order
functions so now we do the same kind of games we did with the readable
not so for example we compute this symbolically first so we need to
compute FTL of FTM now afternoon has this code so I just copied it
here and renamed it to and CA to instead of the yarns yeah because
we're going to have AR NCA all over the place you know and so I'll
be confusing so I remained up now I have FTN of this so what is that
last um is this function where instead of CCA I have to put in a set
this function so that\textsf{'}s what I do I copy this code and replace CCNE
with this to notice that now I substitute so any r2 is the argument
of this function which is now being applied to this so and so the
pr2 I write this so let me do not I get this they are going to see
CCA of c2 c2 and then instead of a until I wrote that so for I'm just
mechanically substituting I'm not trying to simplify much as long
as I don't have to I just substitute an argument into a function so
that\textsf{'}s the symbolic evaluation of this now let\textsf{'}s compute a sniper
vestian so that\textsf{'}s Earth Map I'm just copying from this method over
here and instead of F I put FTM so now I substitute FTM code and I
get this now I apply F TN to that so f TN of Earth map of T an old
CCC a so now at the end of this and just copy that over yet now I'll
substitute f GN of x equals this and X now is this function and so
since X is this entire thing I get to call X on this argument and
X has one argument which is BR so instead of BR I need to write this
total PR so let me do that I have that and I'm still here BR here
because I don't want to make it too complicated but BR is basically
this and now if I want to simplify this further then what I can do
is I can say BR of this yes well I can just put it in there CBR has
one argument instead of that argument I have this function the body
of BR is applying this function to a hard one so basically instead
of AR I must use AR one and then I like to write this as a result
so that\textsf{'}s the result with AR one instead of AR the final expression
is this now if you compare that which is here and that which is here
line three three five one three five five they are exactly the same
functions except you need to rename a to see a two and AR one to VR
so that\textsf{'}s the proof that they are the same code you can go with rename
and you get this income so now let\textsf{'}s look at these two examples so
this example is a useful semi do not what is not a full more that
I talked about this example in part 1 of this tutorial so this is
a reader one out with the type for the reader value sorry it\textsf{'}s a right
your motive not a reader mr. right your model the type of the writer
value is a product of v MW and that needs to be a semi-group so what
semigroup law do I use the same rope is that from the two V\textsf{'}s it takes
the left one but from the two w\textsf{'}s it takes the right one so this is
an interesting semigroup which is not trivial but it is another group
it\textsf{'}s not a monoid cannot make it into a monoid and so because of that
you cannot make this thing into a formula but this is nevertheless
a useful example now let me give you examples of incorrect implementations
so here\textsf{'}s an implementation where it is a writer monad and the writer
type consists of a product of WNW but the flattened function uses
this this computation so it takes it ignores V it takes W 1 and W
2 inputs the millander in the opposite order so the type is correct
but we'll see that the subjectivity law fails so alternatively we
can say this fails because the pannier w w is not a semigroup when
we define the binary operation like this when we ignore the first
two and we take a second to and reverse the order so let\textsf{'}s just verify
that this is not a semigroup but the social tivity fails for for the
same 804 this would be similar and that\textsf{'}s the here\textsf{'}s a numerical test
we implement this combine like this so we take ignore P 1 we take
P 2 and reverse the order of the parts on that tuple so then we have
the tests so combine 1 2 3 4 gives you 4 strip that\textsf{'}s the definition
and so then let\textsf{'}s take 1 2 3 4 5 6 if we first combine 3 4 and 5 6
and then we combine the result with 1 2 and the first combine will
reverse the order of 5 6 and the second will again reverse the order
5 6 so then the order will be unchanged but if we first combine 1
2 \& 3 4 and then 5 6 then we'll get 6 5 so associative 18 is obviously
failing and the second example where associativity is film is that
we take a list and we define flatten in non-standard way it concatenates
the nested lists in reverse order so in other words we just define
it as reverse and then flatten so instead of I would say reverse one
reverse one everywhere and then we do the computations that we did
before in a triple nested list and we see what happens so the first
flat it turns you this order but the second first you give a map and
reversed pile and one reverse button and gives you a list of elements
in a different order so they're not equal so once you start changing
the order of things you break a subjectivity and this is because if
you first flatten the two inner lists then you reverse the order a
new flat and the outer list you can reverse the oilers the order a
different way then if you first reverse the order within the outer
part so this numerical example shows you how that works so we have
done computations with semi moments so far we have been looking at
flat map only or flat and looks like the lowest 420 and that\textsf{'}s a semi
moon now film will not have additionally a method called pure here\textsf{'}s
motivation as to why that seems to be useful as I was describing the
front in the previous part with part 1 of this tutorial moon and represent
values that have some kind of special computational context either
they are evaluated non-standard way order many of these values extra
value attached to them or some forest and monads would describe methods
we would describe values that have different kinds of values of the
context so you could have you could imagine for example for a list
the context means you have several values so you could have a large
list or smallest so specific monads will have methods that trade there
is different contexts another example is the ether moment that has
an error value and a successful value and you could have different
error values for example so these are different contexts now when
you compose monads then the contacts are combined in some way and
as we just looked at the laws we find that the contacts need to be
combined in an associative way so context in some sense make make
up a semigroup for a similar that the contacts combine in a way that
is associative now generally useful would be to have an empty contacts
the contacts that you can combine with another context and that doesn't
change that other contexts so some kind of a neutral element so if
you think about contexts as values which is not always possible directly
but it is possible for example for the writing movements so the writer
more of this a good example where you have a value and another value
which represents the context and this value is explicitly combined
with other such values using a semigroup and so that\textsf{'}s exactly what
happens in general with monads except in general you cannot say that
the moolaade is a product of a and some value it\textsf{'}s not some so in
general but contexts combined associative way and if you have an empty
context and it will be like a neutral element or identity element
of the context set its and so combining empty context and another
context should be a no op and should not change another context so
that\textsf{'}s the motivation and in algebra we have a binary operation with
a neutral element analysis that\textsf{'}s a monoid associative binary operation
with a neutral element and so in the writer monad the type W is required
to be a mono in the writer semi Munna it\textsf{'}s required to be only a semi
group so what does it mean an empty context specifically for a muna
it means that you have a function called peer which has this type
so for any value a you can create a monadic value ma that contains
in some sense this value a with an empty context or neutral context
no effects if a monitor represents some kind of effect some kind of
side effect then this value has no side effect so when you combine
this value with another monadic value that has the side effect then
that one out side effect is not have not changed so that\textsf{'}s that\textsf{'}s
the idea let\textsf{'}s useful to have such a such an element for mathematics
and so we hope it will be useful also for programming in fact that
is not so useful for programming you don't often use this method you
use it sometimes but specific ones need to have many more different
methods to create various non empty contexts as well as empty contexts
if the only thing you could do is create empty contexts it will be
impossible to use a moment for anything useful so certainly any specific
one that needs more methods than just pure and flat nut but from the
mathematical point of view as we will see this requirement that there
should be a pyramid is a useful requirement it constrains the types
in a useful way it kills off quite a few implementations that cannot
admit this kind of function with correct laws and that\textsf{'}s a good thing
that you mean you know there\textsf{'}s as we have seen well see later part
of this tutorial many many more semigroups than mana with many many
more semi models the Mona\textsf{'}s so it\textsf{'}s useful to constrain the types
in some mathematically motivated way so what are the mathematical
properties that we want now the two properties that I just again written
up here in terms of code so if you make an empty context it means
you are in certain the given value le into the monad with no extra
computational effect or context or anything then this value should
act as a no hope so as if you did not actually use them on that so
for example this code or you iterate let\textsf{'}s again think about lists
as mu not so we iterate first over this container and then over this
container but this container is only one value which is this X that
you inserted and so this code should be equivalent to this and the
code that you want is let\textsf{'}s say you have a pure of X a flat map with
that and that should be the same as count of 1 which is X context
in the short notation it is a pure followed by flat map and it should
be the same as the function if I'm your thunder and the second is
that when first you have a generator and then you do a pure so just
like we did in the associative also you need two situations when your
construction is before a generator and your construction is a storage
generator and in the second case that pure will be inside the flat
map so that should be exactly the same as this should be should be
able to simplify your code if you have this into this code and that
is account flat map of X going to pure of X so that should be the
same as just cont so this should give you exactly the same container
as before and so that means flat map of pure is identity function
so these are two was the called left identity and right identity at
this point is not obvious why they're called like this and we will
see children so there\textsf{'}s an additional law in fact for pure it\textsf{'}s required
to be a natural transformation so pure is a map between a and M a
sub a is the identity function and when is the MM functor so it\textsf{'}s
a map between two factors required to be a natural transformation
and that chirality law looks like this difficult for materiality you
interchange the order of some arbitrary function with your thumb in
the natural transformation and that should work you need a knife map
on the right hand side and here are the types so you start with a
map to be and you insert that into the moolaade using pure ore you
first insert and then here F map the moment and that should be the
same result a left identity looks like this so let\textsf{'}s substitute the
definition of a flat map in terms of flatten which is f my path followed
by flatten and then we have the law that F pure flatten it is F for
any F which means that pure followed by flattened is identity but
here F must be given your type inside the Munna so the both side of
this identity must be applied to as a just with some weight so that\textsf{'}s
how it works some types of you start with some si the pure must be
applied to the data so it gives you an SOS a so it\textsf{'}s a pure that is
applied to this type gives you a source a and when you flatten not
give you back a say that should be identity so this should not introduce
any extra effects or anything the right identity is similarly you
substitute the definition of flat map in terms of flatten into the
flat map of pure again F map of pure followed by flat that should
be identity again both sides are applied to a type si so F map of
pure is inserting a into the unit under s so that sa ghost SMA and
it\textsf{'}s different from this where we just applied pure to si as if that
was some B so ever say this essay is just some B but here we don't
be with her F map so I indicate this by putting a type parameter of
pure explicitly just to be sure that it is clear what we're doing
so this is a different function this is a pure and this is a hash
map of pure although they work on the same types and then you flatten
and that should again be identity so in this formulation it is shorter
so you know then a formulation of Lois with like that but still it\textsf{'}s
not clear why these are left and right identity laws what is left
and what is right here exactly well you can say for fom pure was on
the right and here P Rose on the left but for flatten it is not for
flatten both times flatten is on the right so we'll see why does it
so but we know this either the laws in order to understand more deeply
why what\textsf{'}s happening here and why we're writing the laws and talking
about them as right and left identity let\textsf{'}s recall how we formulated
the laws of filterable factories so we used the F map hoped which
have the this type signature and then we found that we had to compose
quite often functions of this type a t1 plus B so a t1 plus B and
then beta 1 plus C we define an operation which we defined already
denoted like this to compose these functions so we have a very similar
type signature here the flood map except that this was the option
factor but this one is the same Thunder s as here so let\textsf{'}s try to
see if we can compose these functions so these are closely functions
this is just how they're called a class-d function is a function of
type it goes to s be where s is a certain factor so it\textsf{'}s kind of a
twisted type it\textsf{'}s a function but it\textsf{'}s life is a bit twisted and so
because of the twisted type you cannot directly compose them a to
s be beta SC kind of directly compose but using flatmap you can easily
compose of course notes f8 o has been G beta SC and then you just
take firstly apply F to some a you get an SD then you apply flatmap
G to that s be so flat map G I goes from s B to C so you can easily
compose that with us so you can post flat map G with F and that\textsf{'}s
the definition of what we call the closely composition which is denoted
by diamond now further filterable factors I have the super had the
subscript opt under the diamond just to remind us that the option
is the optional factor that is being used to twist the function type
in the classical function here it is the founder s that is being used
for the class Li function type so if I were to be completely pedantic
here I would have used diamond with subscript s but that would be
a lot of extra symbols and actually we only have diamond s everywhere
we don't have any other factors except s right now and so let me just
her gravity always diamondden I mean diamond s so diamond defined
like this where this flat map is for the same unit s or for one address
we defined the class Li identity which is a function of this type
and that\textsf{'}s just a pure the pure has the right type so now let\textsf{'}s see
what the laws are so the composition law actually {[}Music{]} can
be written like this because the composition law has flat map of F
followed by flat map G so it\textsf{'}s like this so basically the composition
law for flat map which is similar to that of f map opt from chapter
6 this composition law shows that flat nervous some kind of lifting
it takes functions of these types and it produces functions of these
types and such that composition of these functions corresponds to
composition of those functions after lifting so of course on the left
are slightly composition on the right there is the ordinary composition
but this is very similar to lifting and the laws are similar to function
if ting laws as we will see so what are the properties of this closely
operation so let\textsf{'}s reformulate the laws of flat map in terms of the
class the operation a class decomposition a diamond so the formulation
becomes a very elegant set of laws so that left and right identity
laws are like this so pure composed with F is if F composed with pure
is f now here F must be one of these functions in now it\textsf{'}s obvious
why they're called left and right identity loss pure is identity and
this is exactly like a binary operation in a mono ed which has left
identity right identity associative eighty law is written like this
which is very concise and it follows directly from flm law because
they're phalam law all you need to do is you write the FLN law which
is this the that equals that and you prepend it with some function
f arbitrary function f and then you rewrite this by definition F followed
by flatmap is the Dimond operation so that becomes directly the left-hand
side from here and the right-hand side from here now in written in
this way the laws are very suggestive of a monrad so these laws express
amyloid of functions where the binary operation is the diamond composition
or the classic composition the functions must be all Class C functions
so they must all have the as twisted type a to s be for some a and
B and pure must be a natural transformation that is of the type a
to s a and so this is why you hear that Vinod is a mullet in a category
of and the factors now I don't point explaining the details of this
because actually after studying it I found it\textsf{'}s not very useful as
a description of what a monad is what is somewhat useful however is
to look at the laws of the moon ad in this formulation it is actually
not very convenient to program with this operation the diamond is
also not very convenient to check laws for it because of the complexity
lose all these type parameters and arbitrary functions that you have
to keep but the formulation of the laws is certainly the most clear
and suggestive so so this is a monoid in certain sense so on the set
of functions of this type so if you consider just a set of functions
of this type for any a and B then they form a monolid together with
this as this empty element or neutral element or identity element
whatever you want to call that and the operation which is the diamond
so after this let me explain what is this category Theory stuff about
and why we want to use it until until now we have seen several kinds
of liftings that mapped functions from one kind of functions to another
and so let\textsf{'}s try to generalize all these different liftings that we
saw so far we have seen liftings of plane functions until these kind
of functions lifted into the Thunderer F this is an F map so f map
was lifting from here to here we have seen F map opt which listed
from a to option B into FA to FB so this was option and for some F
the filter of the functor and this is now we have seen a lifting of
this to this directly with the same factor nicely over half is how
we call these functions nicely functions with 1/2 F or earth closely
functions over factor f in each of these cases we saw an identity
function also being present in some way except that in the closely
functions the role of the identity function is played by the pure
the composition was given by ordinary function composition of these
first two cases and by the diamond operation in the third case however
the laws are the same left identity right identity and subjectivity
of composition so category theory generalizes the situation and says
that the difference between these situations is just in the type of
functions that are being used and the kind of composition that is
being used other than that situations are very similar each of these
are called a category and so to say I will present a very concrete
view right now which is that category is basically a certain class
of twisted functions which are denoted with this squiggly arrow and
in different categories these types of these functions could be different
so here are the three examples we have seen so far so twisted functions
are called morphisms in category theory and you have to specify which
category are working with so usually we work with playing functions
and sometimes we work with of Indies now category must have certain
properties these properties are that for any to morphisms there must
be a composition morphism and the type you must be like this a to
B B to C A to C now the squiggly arrow remains the same it could be
each time this or each time this for each category the second axiom
is that for each type any there must exist an identity morphism which
has this type and the other two axioms are identity loss and associativity
law so if you have found somehow the type of twisted functions or
morphisms like this and you can define identity morphism and you can
define the composition such that the laws hold then you have defined
a category that is the idea so category is kind of an a twisting of
the idea of functions and the value of this generalization is that
you can now define factors in a general way as a map from one category
to another so for example a map from this category to this is a functor
when it preserves identity and compositions these are the functor
laws identity in this category must be mapped into identity in that
category so if you lift this twist and you must lift this to that
and composition of function in this category or morphisms generally
composition of morphisms must be lifted into the composition of lifted
morphisms in this second category and this is the same for all these
lifts so for example lifting from here to here same properties must
be so it\textsf{'}s flat magnet lifts but the properties are the same it preserves
identity and compositions are the three laws that must hold now what
we called functors so far in category theory is called endo factor
so what we call functor is a lifting from here to here and this is
called endo factor but category theory has a lot of terminology that
is not particularly useful in programming just a terminology that
is useful is what I'm talking about here so I just tell you about
this in case you encounter this word basically this is just factor
and it just goes from plane functions so I would say in my terminology
the category of plane functions is just ordinary functions with ordinary
identity in ordinary composition but the category of functions lifted
to a founder F or type constructor F let\textsf{'}s say is a category of functions
of this type with identity like this and composition is still the
ordinary composition class by category over from a third constructor
F is this and then you can demand the properties of lifting and that
would make it a functor or if you lift from here to here that would
demand it to be a mu naught and so category theory in this way has
a very concise language it allows you to define things like functor
and monad just by saying this is a certain category that you you've
got to lift from this category to that category and that already tells
you what the rule must be what the laws must be everything the definitions
it\textsf{'}s a very concise way of talking things that a high level of abstraction
but at this level of abstraction not much code can be written directly
and so I I think this is kind of optional term to go this far and
so as a last kind of abstract slide here I will show that if {[}Music{]}
if these classic functions form a category for a specific type constructor
s then it is a monad so first thing to notice is that if you are given
just a class decomposition and the the pure operation and you can
define map and flatmap for your type constructor so here\textsf{'}s how so
flat map of F is class decomposition of identity and F now this identity
is an ordinary identity is not pure it\textsf{'}s just ordinary identity of
this type and it can be closely composed with F by pretending that
this is some type Z and so this is z2 as a and F is a toe has been
so the result would be z2 as but Z is si so that\textsf{'}s how it works so
we can use identity ordinary identity and we can use the viewer and
we can use the ordinary composition and we can use the class Li composition
using those we can define map and flatmap so here\textsf{'}s how well the help
is defined through class Li like this it\textsf{'}s just a flat map of a pure
function which we'll see here so actually it turns out that we need
to require two additional materiality Louis for peer which are {[}Music{]}
written like this and they connect ordinary composition closely composition
F map and peer so what I believe is that if somebody gives you just
the Kleiss Lee composition operation and the pure we still have to
verify that these laws hold it must be natural transformations so
these laws kind of say that F followed by pure is kind of similar
to closely functions if you have a non closely function have ordinary
type you just take on a pure at the end of it and you get a closely
function and then it behaves as a class Li function so ordinary composition
can be replaced by closely composition and if you have an F map of
an ordinary function then you can pretend this is a Class C function
by putting it into pure and then you can do this so in this way you
can also compute f map because you can put identity on the left here
and then you get a live map with identity of G and pure and so then
once you define in this way I can assume these laws the laws of pure
and flatmap follow from the category noxious indeed so left and right
identity laws or immediately discovered if you're right in this and
for example this is just identity law because you can take any function
nicely composed with pure and lets that function itself so if you
write this and you write down the class like composition {[}Music{]}
in terms of flatmap then you get left and right identity tools it\textsf{'}s
social do it if your flat map follows like this when you write this
which is true and write it out and substitute flat map like this so
identity diamond def is flat map F so this is flat map F and then
this is another flat map of F G which is a flat mapping in this guy\textsf{'}s
where this F followed by flat man G so you just write it out and you
get the Loess enough left naturality which we assumed here allows
you to compute this which is kind of interesting fpou G H is f G H
so there is a kind of a weird associated between going on here between
ordinary composition and classic composition which is interesting
and very useful for computations so then you get naturally for pure
for example by writing this this is our neutrality assumption and
you get the natural D for pure out of it out of that flatten has defined
them as identity diamond identity with these types and that rally
for flatten can be found by saying well what is this it\textsf{'}s flatten
his identity diamond identity f map his F pure using this definition
then you simplify you get identity where this thing can operate here
is identity in diamond sometime so identity diamond something is F
map of that something so then you can get rid of one of the identities
you get this and the other side of the flatten that trowel tool is
double F map which you have to write out so you write it out then
you get this identity it can be simplified the way then you have again
finally you know just this and these are the same so in these in this
way I can derive from the moon applause I can derive the closely packed
category lows and from plastic category rules together with these
extra nationality assumptions I can give the Monad laws so let\textsf{'}s go
back to a more concrete world where we combine contexts associative
way and in the semi monad that\textsf{'}s sufficient the context are combined
as an SME group but an effeminate the contexts are combined in as
in the monoid they have an empty context which we can insert and so
let\textsf{'}s see what mono is are what are the types that have the property
of being semi groups and one works there are quite a few examples
of semi groups and monoids and there are some specific examples that
have particular nature for example for integer type in many ways of
defining a monoid you can have a product some maximum minimum different
kinds of semi groups and monoids for string for example you can define
different models different semigroups concatenating strings with separators
for example in different ways for the set type you can define intersection
of subsets or union of subsets as monoid operation another interesting
example is the route type in the a collider in the HTTP which has
an empty route that always rejects everything and the route concatenation
operation that puts one round on top of another and combines them
and that\textsf{'}s a manorial operation but these are kind of special and
here I listed some generic constructions of Mao\textsf{'}s so that you could
appreciate how to build new monoliths from old ones and what kind
of properties are required for a monoid so let\textsf{'}s now go through raising
examples the first example is that you take any type and you make
it into a semi group and that\textsf{'}s very easy you just define a combined
operation that ignore is one of the values so for example you just
delete the right value ignore the right value you take the left value
and that\textsf{'}s your result that\textsf{'}s how you come back this is a kind of
a trivial operation that combines non-trivial perhaps not very interesting
way but it satisfies associative it let\textsf{'}s see why here\textsf{'}s an example
I define a 7 group for anyway and now any types are combined and ABCs
of strings integers everything is combined in this way now after I
define a simple associativity for example here\textsf{'}s ABC and I combined
them in two different ways and there\textsf{'}s always always a so why is the
social TVT correct that\textsf{'}s because in any combination of these the
operation will always between the leftmost value all the other values
will be simply even ordered so obviously this is a so associative
you are deleting all values except the leftmost value and it doesn't
matter in which order you do need them and similarly the right trivial
semigroup which ignores the left value and returns the right the next
example is already seen in the previous chapter where you have a selling
group and you add one to it so you have an option of a semigroup I'm
not going to go through this but the laws are satisfied as long as
that is a semigroup so identity laws are satisfied by construction
and the semigroup laws are satisfied that that is a semigroup another
example is the list list as a monoid for any type of sequence and
so on because you can concatenate lists and that\textsf{'}s a valid operation
and the empty element is the empty list so you can catenate empty
list with anything and that doesn't change that other list so obviously
it\textsf{'}s associative because you just concatenate the lists in the order
in which you have written them and so that doesn't depend on the order
in which you remove parentheses between the lists this construction
for is also generic so it\textsf{'}s for any type a it\textsf{'}s a function from a
to a that is a monoid the operation which I denote one this it could
be a composition of functions in any specific order so there are two
different one if you choose one order of competition or another so
let\textsf{'}s look at this left composition or you say X and then Y for the
combined operation and the empty element is identity function so obviously
the composition respects identity and subjectivity is clear because
you apply X then you apply Y then your plan Z so the order in which
you apply x y\&z is the same and it doesn't matter in which order
you put parentheses here that\textsf{'}s left composition as a right composition
when you write composed instead of and then and compose is X compose
Y of a is X of Y of a which is the same as Y and then X are we first
you say y avait and then X of that identity laws are again obvious
associative it is again easy because X compose why compose is basically
this X Y Z there\textsf{'}s no way and the order is the same and there\textsf{'}s no
way that this can change and so doesn't matter where you put parentheses
here parentheses in here are unimportant the next example is total
order type well this is also a generic kind of example of any total
order types in the enumeration or integers so the only thing from
on the way you need you need a maximum or minimum so if each have
maximum as your binary operation you need a neutral element for a
monoid and you might not have a neutral element for example for integers
there is no maximum integer if you if you use arbitrary precision
integers if you use finite integers then there is it max int so you
could use that associative 'ti is clear because you take a maximum
of several elements and doesn't matter which order you compute the
maximum it\textsf{'}s going to be the same maximum or minimum the next example
is the product so if these two are seven groups or monoids then the
product is also a semi group or a monoid let\textsf{'}s see how that is done
so I'm defining a one or a typeclass instance for the product given
that these two were monoids the empty is a pair of two empty elements
and the combine is a component wise combination so I have monoid operations
separately in this one against two and because they are performed
separately in each part of the tuple then each part of the tuple separately
will satisfy all the laws because you can just delete the other part
of the tuple temporarily and look only at what happens to one part
and then obviously you just have the first one oh it you assumed its
laws already hold or or Senegal and so obviously then the entire tuple
will also satisfy the laws the next example is the disjunction of
Tim seven groups are monuments which is kind of maybe less trivial
than a product so here\textsf{'}s what we do here it\textsf{'}s a right biased either
we have to choose if it\textsf{'}s left biased or right box up to two different
ways of doing this so there\textsf{'}s not there\textsf{'}s not a symmetric way of combining
two semigroups or two more nodes into one but even either the left
side or the left on the right side must be and chosen as the main
side in particular the north and it\textsf{'}s neutral overland and it must
be either on the left or on the right there\textsf{'}s no nowhere to do to
do it symmetrical unlike in the product case so let\textsf{'}s say we have
a right biased either what does it mean well here\textsf{'}s how it works we
need to combine some values of type either a B where a and B are both
mono it I'd say if all of them are left all of these others are left
then we combine their values they're all values of type a so we can
combine them into a left of some eight if they're not all of tied
left already then at least some of them are right a right of B then
we discard all the left and we combine all remaining right of the
operands into one right that\textsf{'}s that\textsf{'}s the idea now this would be associative
because we just formulated the rule that doesn't depend on the order
in which we apply that rule so discard all operands of type left a
dozen doesn't depend on the order in which we discard and then you
combine all of them into one using the monoi operation which again
my assumption is associative and so identity element must be the empty
element on the left and then clearly combining it with the left will
produce correct results combining it with the right will produce there
the right now you without change because you discard the left and
you just get there right so that\textsf{'}s why it will be respecting all the
laws so here\textsf{'}s an implementation so I'm writing down a monoid typed
class instance for either a B given that a and B are monoids the empty
is the left of empty a so we have chosen a right biased either so
then the mono of the empties on the left now how do we define combined
well we have two elements either could be a and B so we match there
for combinations left and left we combine right and right we combine
if we have a left on the right then we discard the left so in the
first case we we must do this because if if X is empty then the result
must be this and there\textsf{'}s no other way to implement that so once we
implemented in this way the laws will hold by construction here\textsf{'}s
an example how this works left one right two left three I'm just using
the integer bond modulus addition then all the left are deleted in
the right to remains right one right two left three the left are deleted
so right one right two remains are combined into right three so for
example u 2 and Q 3 deletes this keeps right - and another example
so again left is deleted right and right are combined the next example
is construction it if we have a monad can type constructor in and
Illinois s then M of s is a manured kind of an interesting example
because now you can construct a lot of types as more nodes if you
have some standard monads and your planet to one law it\textsf{'}s constructed
previously so here\textsf{'}s how it works I'm defining a typeclass instance
for semigroup so here I will only check the seven group not a full
monoid and actually exercise one will be to show that it is a full
moon would if if M is a moon odd then M is a monad s is a monoid an
M of s is a Mulla Mulla well I'm only going to use a semi monad and
the semi group so I only need to define the combined operation so
how am I going to define that well like this very interesting elegant
piece of code X is a monadic value with s y is another man Alec value
so I just combine them using them monadic combination and semigroup
combination so associativity follows because if you do this then you
would have called like that and if you first do the first two that\textsf{'}s
what would be if you first computed for yield with these two and then
inserted it into another for yield here which is exactly the first
the the associativity law for for the Monad which is that you can
inline parts of your for yield block into a larger for yield block
so that associativity guarantees associative 'ti at this level and
then the semigroup which is being used here must be assumed also to
be associative and that guarantees associative et in the last line
so it\textsf{'}s kind of very easy to assume that this thing is associative
without going through a lot of a lot of computation and coding as
we did before and an example of when it becomes a full mode let\textsf{'}s
take a reader model reader monad and apply it to a Molloy yes so the
empty element is a function that takes an argument and return the
empty value of the mundo it and the combined two readers is to take
the Z and we apply x and y 2z and you combine the results and so basically
all the neural operations are performed with the values of s that
you've obtained by applying functions to some Z so for each fixed
value of Z once we apply this function you get a monoid valued and
all the laws hold so they hold separately for each value of Z and
so they always hold for all Z and therefore a function from Z to a
moon or it is itself a monolid and Z doesn't have to be infinitely
it\textsf{'}s just fixed type doesn't have to be moderate adorned the final
construction is more complicated and it\textsf{'}s motivated by some mathematics
but actually it has applications in practice so the construction is
a product but only one part of the product is a semigroup and the
other is not necessary necessarily a semi-group so SS is similar but
P is not P is just some type however the semigroup pacts on P so it
has an action loopy and that is what makes makes it possible to define
a semigroup on this product what does it mean that s was an action
on the P and actually the function from s to a function from B to
B so for each s there is a transformation of on P and these transformations
must be such that their composition corresponds to the non-oil composition
of s so this is in mathematics a typical situation then let\textsf{'}s say
the group acts on a vector space there is a transformation and multiplication
of transformations corresponds to group multiplication and here we
just use a semi group and that\textsf{'}s sufficient so the result is a product
s and S\&P which is called the twisted product so it\textsf{'}s we wouldn't
be able to define a semi group we define a semi group using this action
without this action would be very very useful we could define a trivial
selling group with one of these ignoring operations but I wouldn't
be very interesting so here\textsf{'}s an example of such situation if s is
this which is something then it acts on a because for each function
you can transform this P alpha is identity and obviously it satisfies
this law because the composition of functions is the same as composition
of transformations another example is a product of boolean and an
option of a where you can act with boolean by filtering so filter
operation satisfies this law because as we know from the properties
of filter balls filter composition with another filter is a filter
with boolean boolean conjunction of two boolean values so if we define
this semi group as boolean conjunction then the filter would be good
so this could be any filter it\textsf{'}s not notice is really an option I
just put here an option as an example but this could be any filterable
so this is a generic example of a semi group with a non trivial structure
so we're going to show you some code for this twisted product so here\textsf{'}s
how we define it so I'm defining a semigroup instance for don't actually
doing this I have a single group s in a3 which is unknown type and
I have an action has to be 2p and then I can define a semi group of
SP with this combined operation so the first element of the tuple
is combined using the semi group actions a semi group operation but
the second one is an action that puts together the first X so the
first semigroup and the second P so the first one here packets on
this and that\textsf{'}s the result so that\textsf{'}s kind of a twist and here I can
verify symbolically that associativity works I consider this definition
so that is I just defined other things and then I consider three different
values and their combination in two different orders and the result
would be that the actions would be like that and they should be the
same and there will be they're going to be the same as long as the
action a satisfies the property that we assumed in other words a FS
1 over L of s 2 of P 3 is the same as a of s 1 plus s 2 of P 3 so
and that is so let me just give an example where we define a semigroup
using a boolean and an option int so boolean acts on any filter mode
using the filter function so optional suitable we're just using a
standard library for naught and we define this implicit value of semigroup
for Q for the type Q by calling that function we just defined and
I see that the values work and there is associative it now these are
just very simple examples I'm not sure this is extremely useful to
filter options with boolean but this could be useful in some application
perhaps in any case these are the generic constructions that you can
use to make new scenario humanoids out of old ones in the heart of
other parts with this as inspiration let us now look at what are the
constructions of possible semi models in Malad our intuition is that
the best for analysis is to consider the flattened functions as the
simplest type signatures simplest laws and the way if flattened works
this text data in this nested container and somehow fits that data
back into the original container and this should must be a natural
transformation so you don't actually perform any computation with
this data other than reshuffling it in some way now you have seen
examples of monads and you have probably asked yourself a question
of what are all the possible Muna\textsf{'}s are so different how do I know
that the given type is a unit or not in fact this is an open question
I believe it is not obvious that we have an algorithm to decide whether
any given type expression is a monitor or not and as you have seen
it\textsf{'}s a bit cumbersome to verify the laws of the moolaade but here
are some constructions that I found that always give you lawful monads
and so if you construct a monad using these then you don't need to
check laws you can prove this in advance that all these constructions
give you correct units and then you just use them you don't need to
go through checking the laws every time in your application whatever
you define new data type with a unit instance so all these constructions
use exponential play level types so they are either products or disjunctions
or functions function types so the simplest construction is that of
a constant factor and the constant factor is semi Malad for fixed
type disease but it is not a fulminant because the identity laws cannot
be satisfied unless the type G is unit so the only constant factor
that is am honored fully model is a unit type constant factor so let\textsf{'}s
see why that is so let\textsf{'}s define this type constructor with Z type
parameter which is that constant and he is a functor type parameter
that is not used in the actual type because it\textsf{'}s a constant factor
so the function is going to be written like this in the syntax for
the Skull kind projector plug-in so here\textsf{'}s the inst instance of a
semi mullet we just do nothing flatmap returns the initial value with
no changes ignoring this function that is given there\textsf{'}s no changes
because you map a to some something else but there\textsf{'}s no way for you
to there\textsf{'}s no a there\textsf{'}s no way for you to use this function if so
you can't call it you have to return this Z so your Z is just stays
the same flatten is identity flat map is identity F map is also identity
because there\textsf{'}s no a to total transform and so associativity is trivial
there are other entity functions composition of identity functions
is identity however this is not a fulminant the right identity law
fails here\textsf{'}s why the right identity law says that flatten of pure
of some X must be equal to X for all X now what can pure do pure goes
from A to Z it cannot do anything except give some fixed value of
Z suppose I give you some fixed value of Z for all a there\textsf{'}s no way
that you can use the value of a 2 let\textsf{'}s try that so pure actually
cannot depend on its argument and therefore pure of X does not have
any information about X it will be a fixed value of Z that\textsf{'}s independent
of X and flatten of that cannot possibly restore eggs the only exception
is that if if type Z itself is unit then there is only one value of
x you can always just put it in pure returns one flatten of that returns
one and that\textsf{'}s the same one that you had here everything is just always
equal to unit and so in that case identity loss hold so that\textsf{'}s the
only way in which a constant factor can be am honored and fully lawful
one world as well as a unit constant fuck factor otherwise it\textsf{'}s a
seven moment 

the next example is the construction of a semi mullet or a monad which
looks like this for any factor G we take the tuple of a and G of a
and that is the new type constructor F and we will now show that in
general you can define a semi mullet for F and if G is unit that is
there\textsf{'}s no G here just a that\textsf{'}s the identity function and that\textsf{'}s a
full moon that there\textsf{'}s no other way that you can get full mana out
of this construction so how do we show this first of all we need to
define the function instance for this and then we'll define a semi
Menard instance define the Phantom instance we need to produce an
implicit value of type factor of F but actually F is not defined as
a type constructor because we have this arbitrary function G so we
cannot define the type constructor F without first defining a G directly
so instead of defining it directly we use the kind projector and so
then this syntax will represent the type constructor that takes a
type X and produces the type of tuple X and G of X and so we will
have to keep writing this extra type expression instead of F which
is okay if you don't have to do it for T many times later we will
say we're looking a little calm down in this repetition so the factory
instance for this type constructor is straight forward we need to
implement the function map which takes an FA which is a engine way
it takes also a function f which is arbitrary an arbitrary function
of arbitrary type it to be and we need to produce a tuple of B and
G of B so to do that is relatively straightforward and unambiguous
we use the fact that G is already a functor so G already has a map
function of its own we use the type constraint here typeclass constraint
so say that G is a factor and we have imported the syntax for the
for functors and so now we can just say g g a dot map so that\textsf{'}s what
we do here using the factor map from the front row G so how do we
produce a tuple of being G of big well obviously we have a tuple of
a and G of a so this is the stupidest structure it using a match expression
obviously we need to use the function f to produce anything that has
been it because there\textsf{'}s no other way to get any any kind of be acceptable
using F so we call F on a to be get a value of type B here and we
do a G a dot map F and that gets us G B so that\textsf{'}s easy enough now
how do we define a cell or not this is a little more involved so again
we assume that this is a factor and we are going to produce a value
of type semi Malad of this type structor expression and that\textsf{'}s going
to be the implicit value but this value is characterized by G so we
need to make it a death so the function we need to define for the
semicolon is flat map so how do we define flat map well we have an
arbitrary function of type F sorry of type A to B and G B we have
a tuple a G a and we need to obtain B G B so let\textsf{'}s think about how
that function can be defined and to get intuition about it let\textsf{'}s remember
that mu not represent some kind of computational context or effect
that accompanies a value and so here obviously we have a value of
type a and also a value of type G of a which we could consider to
be the effect or the computational context of the value a so just
intuitively now we have the initial value that has its own effect
that\textsf{'}s the first one and also we have when we apply F to anything
we will get another G will be which is a second effect now clearly
these G of a and G G of B near arbitrary functors we can't combine
them so usually Mona would combine two effects into one so for instance
if this were just the reader Mona that\textsf{'}s that would be a tuple of
a and W and here will be a tuple of B and some other W we will just
combine this w and that W using the semigroup but here we don't have
a second group G is an arbitrary factor there\textsf{'}s no way for us to combine
two values of type G of BC we could try to map F over this but then
we'll have G of B and we can't combine that G of B together so we
have to discard one of the effects basically that\textsf{'}s the basic reason
why this cannot be a full moon usually when they discard effects that\textsf{'}s
red flag in terms of having a full monad film Allah doesn't discard
the two effects it combines them in a mono Idol fashion semigroup
combination can discard but 108 combination cannot discard if you
you cannot defy them annoyed when you define your binary operation
that discards one of the arguments that will be not a lot from annoyed
because it would not have an identity value because you could not
combine identity and X to get X when X is discarded so you're not
allowed to discard if you want to have a mono it\textsf{'}s similarly here
we shouldn't be discarding any effects or any information when we
would like to have a full owner all right so that intuition gives
us a guidance that probably we're going to have a semi monad here
and not a homo not because we have to discourage something there\textsf{'}s
no way we can take into account all this information because we cannot
combine G\textsf{'}s so let\textsf{'}s just arbitrarily decide to describe the second
effect and that means we will basically ignore the second part of
the tuple the function f produces so ignoring the first effect would
mean that we ignore this you know in a second effect means that we
ignore this so let\textsf{'}s just arbitrarily decide that we will want to
ignore the second effect so that means we define a function f1 so
the first part of F which is this so this will apply F and then apply
the extraction of the first element of the tuple which is then basically
means we discard this and then we get the function a to b and now
we just apply this map function that we have before so with a we get
this result this is the same code as was above here so this is one
way of defining a same unit which is really arbitrarily decided that
we want to describe the second effect who would have decided them
we could have decided to describe the first effect instead wouldn't
be also similar than to show this as one of the exercises so let\textsf{'}s
continue now let\textsf{'}s take care of the case when G equals unit and then
we just have the identity function as our identity factor now this
is also the identity monad because just define all the functions as
identity flatmap f map flatten is identity pure is identity everything
is identity and then obviously all Monad laws will trivially hold
because all these laws mean composition of some identity with identity
which should be equal to identity so it\textsf{'}s always going to hold all
those if you define all your functions as identity functions so for
this function you can define all your methods as identity functions
and that\textsf{'}s what we do that\textsf{'}s called the identity monad not a very
interesting will not per se but it\textsf{'}s interesting to note that it is
a unit so for instance this is a functor also not a very interesting
one but it\textsf{'}s important to have that founder as an example because
for instance in a construction you use an arbitrary factor or an arbitrary
unit and you can substitute identity founder or identity monad into
some constructions like one of these constructions that have arbitrary
functional units in them and you get an example of a new unit by that
so identity models and identity functions are not necessarily useless
not necessarily useful directly but they are useful for constructing
new moon and sometimes let\textsf{'}s now go on to verify the associativity
law for the semi moment that we found so for brevity will define type
aliases so f is this you see this is not that this F is not the not
a function by itself good it has two type construction I had to type
parameters so it is a type constructor that has two type parameters
a functor should be a type constructor with 1 type parameter so we
need to write things with the kind projector as we did here in order
to get the right syntax for a functor type constructor will not that
constructor but just for gravity we're going to introduce this notation
these are type aliases so this is fine this is f of GA which is there
but what would you know that there is FA here it is explicitly taking
G as a parameter now F F is just f of F this is just the same as if
we stop writing G and that\textsf{'}s what it won't be and and this is F of
F of F of ad writing it now it would be quite cumbersome so I just
want to introduce these type a leases now in order to check the laws
the easiest ways to look at the flatten function what F not the flat
map function so let\textsf{'}s derive the flatten function probably the definition
of the flat map that we were given above so we given this definition
of flat map and flatten is flat map of identity which and the identity
must be of this type so let\textsf{'}s copy this code and substitute identity
instead of F so that\textsf{'}s what we get now F 1 is a simple function that
just takes the first value of the tuple so we can substitute that
into the code so let\textsf{'}s see I'm going to rename this to FA and this
to G FA because the types of these things are FA and GF this FFA is
of type F F of GA which is this it\textsf{'}s a tuple of F and G of F so therefore
I'll choose my names here fa g fa these names were just copied from
above so I want to rename for clarity to remind myself what types
these variables are so now if when you say here for example f1 okay
but with one is just taking the first element so instead of this I
write this and here I write this so let\textsf{'}s further simplify now obviously
if a is FF a dot underscore one so then this is dot underscore one
dot on your square one and this is FF a dot underscore two map underscore
underscore alright so this is the code of the function f flatten now
this is what I call a symbolic derivation of the code so this code
was derived by substituting function definitions and simplifying but
simplifying is more or less like in algebra you have an expression
you substitute a function into it and for example here FA is FF a
dot underscore one and so you substitute here instead of F a so this
is quite similar to mathematical derivations in algebra so you just
substitute equal values for equal values anywhere and substitute definition
of functions to apply them and then simplify and and so on and so
this is a symbolic derivation of the code I could have just written
this as a definition of flatten this would not be a symbol in derivation
because I don't get the code of the function cannot reason about that
code as easily here is the code of the function that I can later reason
about I can again do the same substitute is simplified and that\textsf{'}s
what I will have to do in order to verify the laws so there\textsf{'}s a there\textsf{'}s
a symbolic clarification that I'm going to do rather than so to speak
a numerical verification if I just wrote this and then used Scala
check to call this function on hundred examples with integer types
or something like that now it will be you know certainly a bit helpful
perhaps to do that unfortunately in this example we're trying to prove
something for an arbitrary function G how are you going to do this
with Scala check I don't think you can do this let\textsf{'}s go check because
there\textsf{'}s no such thing as an arbitrary function in it I don't think
so I will be interesting to add that functionality but it will be
hard to do it just here in this tutorial and this functionality generating
an arbitrary function is this is kind of vicious so you probably need
a lot of code for that so anyway it would be hard to do and it would
only give you specific type parameters and specific functions checked
not arbitrary types and not an arbitrary function or as a symbolic
computation that I'm doing here is more like a mathematical proof
it is rigorous it is proving it correct for all type parameters and
for all functors now if you remember the associativity law for the
semilunar it involves f map of flatten so we need to implement ethnic
let\textsf{'}s do that F map is just the same as map what we did above except
it\textsf{'}s arguments are flipped first comes the function f and then comes
F of a other than that the code is identical now the associativity
law is that this expression is equal to this expression so this function
and this function are identical that\textsf{'}s the law so in order to check
that we need to symbolically derive the code of these two functions
and compare and somehow show by simplifying maybe renaming variables
and such that they have the same code these two functions so let\textsf{'}s
start by computer for F map of flattened because that\textsf{'}s the first
function we need to check is that is f map of flatten followed by
flatten so that\textsf{'}s I just want to remind you is the law of associativity
find that slide this is the law of flatten right here written in this
short notation this is lifting in the functor so this is f man so
basically f map of flatten followed by flatten must be equal to flatten
followed by flatten with types accordingly matching what me back to
this slide and go back to my code so first step therefore is to compute
the code for this so let\textsf{'}s do it how do we do it well with I I do
it by writing out this function as if that were a separate function
I'm defining and code for the body of this function will be symbolically
derived so I call this function as my up flatten just it doesn't matter
what I call it really I look at the COS function in the code so I
name this function just to be sure about what I'm computing so this
function f map of flatten takes an argument of type F F F of a and
returns F F of a because flatten takes F of F of a and returns F of
a and I'm lifting flatten once so I'm adding one more layer of F so
in order to derive the code let\textsf{'}s take the code of F map and substitute
the function flatten instead of F into that code so I take this and
instead of F I write flatten so that\textsf{'}s what is going to be so it\textsf{'}s
going to be flattened of a which is here called f f/a because it\textsf{'}s
that type and then it\textsf{'}s going to be this map F on this map flat so
that\textsf{'}s going to be the result of substituting the definition of F
map in here so that\textsf{'}s first step so now let\textsf{'}s substitute the definition
of flatten which was right here yeah that was flattened so let me
keep it on the screen after we simplified it so that was the code
for flatten so we need to apply this to F FA and we need to do the
so f fa is instead of yeah if FA is right here so we just repeat this
in here and the last part of the to boy is unchanged so I put this
all in comments because this is my preparation now FFA is the first
part of F F F a and G FFA is the second part so then I rewrite it
like this so instead of FFA I write F F F a wand and so on so instead
of G FFA I write F FFA too and so I get this expression which is kind
of a longer expression but this is a this is the code of this function
nested tuple I have a double nested tuple whatever and that\textsf{'}s what
I have to return and the Scala compiler compiles this and so that\textsf{'}s
how I check that I haven't made some trivial mistakes so having compiled
this let us compile as certain having having derived this part let
us now derive this entire thing symbolically so again I wrote a bunch
of things in comments which is how I derived it so first step is to
simply rewrite this notation in scope so rewriting this notation means
you take F FFA first you apply this to F of F a and then you apply
this to the result so in other words in scholar you would apply this
to the result of applying this to F F F a which is written over here
so I just copied it over here so this is now after inside of flatten
and after that we substitute the definition of flatten from definition
of flatten was up there let me look at it again it\textsf{'}s right here so
now I need to take that and apply that definition so this one one
for example it would be just this because the first this is the first
tuple and in the first tuple I take the first part so that is if F
a 1 1 so this whole thing 1 1 it is this and so so I just apply these
things so I extract two parts from here which is immediately possible
notice here I didn't do anything with this F GM inside the map I just
keep it why I can't do anything with it right now I can't simplify
anything in this part of the expression it\textsf{'}s under map so I've no
idea what it is acting on and so I don't know what that is I cannot
simplify any more but later I will be able to simplify maybe so I'll
just keep it like that all right now we got this so this look yeah
I still have this map a flattened with no simplification however now
we can simplify because we have dot map of something don't map or
something else we can combine the two maps and that will be like that
so I just keep the first things unchanged and here I combine first
I take flatten of some things I write out this function as FFA goes
to something if a faith first goes to flight another for a and then
I take the first element of that so however now we can simplify this
flattened followed by taking the first element is just this remember
the cone for flattening respects so the first element of flatten is
this so then I can simplify and this is my result I could simplify
this further I like that at the risk of getting less readable but
we're not going to read this much more hopefully we'll get the second
function now and have the same code and won't be done let\textsf{'}s see how
that goes all right so the second function we need to compute is this
this is the right-hand side of that of the associativity law let\textsf{'}s
do the same thing again so we apply this to some arbitrary fffe and
notice that the type of the return of this function is f so flatten
flatten takes a triple F and flatten this twice and returns a single
nothing here map flatten flatten did the same thing by first concatenate
in the inner layers and this first thing getting into the outer layers
so that\textsf{'}s such a DVD law that\textsf{'}s combining triple F into F doesn't
depend on the order in which you combine the layers of it all right
so let\textsf{'}s continue the first step is to substitute the definition of
flatten in here and so now we have flattened off this let\textsf{'}s again
substitute the definition of flattening now for the outer flat so
we take this 1 1 and so on so once we figure that out it\textsf{'}s going to
be this I'm copying 1 1 and then again the same to map 1 remember
them right there the code is take this FFA 1 1 and then take it to
map one that\textsf{'}s good I'm just being very careful to make no mistakes
so I'm going slowly copying twice now let\textsf{'}s simplify right this is
a tuple we can compute what it means to have one one of it it\textsf{'}s just
this so then we take not we obtaining this so now we have again a
situation with map map we can combine them into a single map which
is less and voila we have the same exact code of the functions we
just look at this code and we see they were the same expression so
this shows the associativity law for the same unit why can it not
be a full moment but mostly for the reason that you can't have a woman
away if you discard information but if you discard one of the arguments
in time but more formally I would say for a full minute we need to
define purer and purer must have this type how do you define it how
do you get a value of G of a for an arbitrary factor G you can't there\textsf{'}s
no way of doing that now if you now say well maybe G is not an arbitrary
factor and maybe there is a function from A to G of a well that is
already suspicious because then maybe G is already itself able nod
or something like that so for arbitrary function G certainly I won't
work we will have a construction three next which is similar work
where we have two minutes a tuple of two morons so let us now go to
example three and I will show that a tuple of two monads or semi womens
is again Amanat or same unit so here I'm preparing the type aliases
first now it\textsf{'}s going to be quite both because I have two arbitrary
Hunter\textsf{'}s G and H and so how can I do anything with them well let me
just do this for brevity and define this notation now notice we have
G of a tuple of G of H of a so this is getting quite complicated each
of a topology of a each way so we have G inside GG inside H and H
inside G and H inside H which is kind of complicated so how can we
define a munna instance products so I'm not going to define flatmap
because it\textsf{'}s much easier to define flat I did define flat map in the
previous example but then I have to define flatten and so why don't
I just start with flatten it\textsf{'}s easier now how do you define flatten
now we have to somehow convert this into this in imagine that we already
know how to convert G of G of a into G of a because G is a unit in
th a very into HIV because H is a moment or centric paalsamy mood
let\textsf{'}s say when we have more than this we have G of two po G of H of
a so there\textsf{'}s an H inside of G how could we flatten that into G H is
an arbitrary type constructor well it is a 7 1 AD or a Mona but it
there are so many different type constructors that fit that description
as we have already seen it seems there\textsf{'}s nothing else we could do
here except to discard the H inside of G and to discard the G inside
of H discarding it is easy because they're factors so we can f map
or map this value with a function that takes the second part of the
tuple or the first part of the tuple for this I can just map like
this and that will discard those parts that we don't want so it seems
this is the only way we can solve this problem and implement for it
let\textsf{'}s do it so that\textsf{'}s going to be the first part map one flattened
so this flatten is M G and the second part mapped to flatten that
flattened image now we have interestingly here a map followed by flattened
so here map fold by flatten this map is also in the factor H as this
flatten this map is a new function G as this flatten therefore we
can combine map and flatten into a flat map and we can write somewhat
shorter code for this flatten function notice this flat map is in
the first element of the tuple which is the function G so this is
the flat map of the semi 1fg whereas this is the flat map of the 7-1
at H there are two different flat Maps really being used here to define
this all right let\textsf{'}s go 125 pure that\textsf{'}s much easier we just take the
pure of the Monon G and the pure of the Monad age and combine them
in an inter tuple we're done with writing a code for the unit now
let\textsf{'}s prove the laws to prove the most women would need F map so what\textsf{'}s
the F map was just a tuple of two F knobs so here\textsf{'}s a little bit of
intuition about what the small knob will do so we have combined two
more hands into one what does it give us so here\textsf{'}s an example so actually
if you look at the flattening you see only g and g are combined only
H and H are combined so the cross terms so to speak H of G \& G of
age are just ignored so that suggests if we do if we write code like
this then there will be no interaction between the two parts of the
tuple so this will interact with this and this won't work with that
so the result would be exactly the same as if we just split it into
two and wrote two pieces of code separately like this and then combine
the results in a tuple like that so it\textsf{'}s just exactly the same so
the result would be for instance here if G is a monad H is a monad
then you would just perform the for yield block separately for G and
H and combine the results in a tuple but you don't have to write it
separately you can rank it when this is shorter than the writing news
so let\textsf{'}s go on to the laws the identity laws are easier to verify
because the code is simpler so let\textsf{'}s start with those two identity
laws the left identity and the right identity now these are at least
two laws so the first law means that a composition of these two functions
is identity so let\textsf{'}s define this composition as a function called
pure flatten so again I have to write all this parameter stuff the
type of this function is f - f so ya go back to the slides and look
at the clause just to see that we have done it right so pure followed
by flooding is identity services this so the type is si - si when
our notation is FA - Fe and the right identity is also half a tuna
Fame so that\textsf{'}s what we do okay so flatten of pure of FA this is what
it means first we apply pure to some arbitrary FA of this type and
then we apply flatten to the result let\textsf{'}s substitute the definition
of pure which is this now we have plot flatten as the substitute the
definition of flatten which is written here this is the definition
so we just substitute it in there and we take the first one flat map
one second one flat map cube now just not much we can do with this
expression anymore unless we remember that this is and this are from
one add H and this and this are from onaji and these monads must already
satisfy the same law which is that pure followed by flat map of some
F is the same as applying F to this X so let\textsf{'}s use that law and that
means we need to apply this function to this FA which means FA dot
on your square one and similarly here so the result is this now if
a is a tuple so if you have a tuple of which you take the first part
and the second part and then put them back together you get the same
tuples you started with so therefore this is just identity function
and in this way we've showed that the first law holds so let\textsf{'}s look
at the second law similarly with good definition of what it means
to have flat map viewer followed by flattened so you take some arbitrary
FFA and you first apply F map of pure of it and then you apply flatten
to the result so let\textsf{'}s substitute what it means so basically F map
works component by component on a tuple so you need to do FFA one
in a pure if you fail to not pure then you substitute the definition
of flatten which gives you a flat map one and flat map two on each
release alright so now we have this situation we have map flatmap
so this is in the factor G and this is in the function H so we can
use a natural T laws for these two factors which we assumed already
hold and if you look up what the naturality lawyers it basically can
interchange the order of map and flatmap that\textsf{'}s what we do so instead
of this this is a naturality law map f flat map g gives you a flat
map F and then G so if we do this then you get for example flat map
of pure and then this so we have such expressions but if you look
at the definition of pure it\textsf{'}s one a deep your coma will not H pure
and so the first part of this is 1 a G pure so then we can simplify
that the result is going to be this again we wouldn't be able to simplify
here but any further except that we notice this flat map is from the
moon LG and so we have a flat map acting on the pure from the same
unit we can use the identity law for that one ad which means that
this is identity function and this is for the moon and H the identity
function and so the result is going to be F FA 1 and then identity
function so we can just delete that get if FA 1 if you fatal and that\textsf{'}s
exactly identical to just F FA something I just something I just noticed
is that the type here is FF and it should have been F so why did everything
compile because this FF type actually is just more restrictive than
F so we should have just changed this to F and things still compile
now I can rename this for clarity so that it\textsf{'}s going to be consistent
so in this way we have symbolically verified the identity laws now
let\textsf{'}s verify dissociative eg law and this is going to be a similar
exercise and substituting functional definitions and simplifying now
notice that we have used the moolaade laws for G and H to derive the
identity laws for the construction F topology image but if G and H
are only semi moments and not for women then we cannot use that but
so we won't be able to derive pure either we won't be able to derive
the laws for the construction so if these are just semi monads then
all the proof of we have done so far does not apply and we can only
prove the same unit for the resulting construction on the other hand
in that proof we don't need have a full moon of the instances for
G and H we only need a semi moon had laws and semi one-eyed functions
where I'm going to use paper for G and H and so if G and H are semi
bonnets then the result will be similar and we are going to prove
that now so if we prove that associativity law that\textsf{'}s what we will
prove buts anymore let\textsf{'}s give us a 1 have you film or not give you
a full minute and and this is because in this proof now we're not
going to use the pure functions from G and H we're not going to use
anything but associativity laws for G H so let\textsf{'}s see how that goes
again we have to do two things we have to compare that these two functions
and show that they have the same code so let\textsf{'}s begin with this function
so flat and followed by flatten I have written out the types for flattened
type parameters just for clarity now let\textsf{'}s apply this function to
an arbitrary FFF a of this type so that means we first apply flatten
to this function and then we again apply flattened to the result so
flatten is this so we apply flatten to the result and there is an
final expression is this so applying flatten to something means we
have a tuple with underscore 1 5 I have a new square one go to five
manners go to this twice so that\textsf{'}s what you get and let\textsf{'}s just leave
it like this we could simplify this because there is a composition
of two flat maps but it\textsf{'}s not clear that this will help so let\textsf{'}s keep
it here the second function is the F map of flat and followed by flatten
so that means we have F map of flatten applying it to F F F a and
then applying flat into the result that\textsf{'}s how it is we again do the
same so applying to F F F a you get the first part of it if FA mapping
flatten so that\textsf{'}s I'm just substituting the definition of F map which
is up here which is you take the first element of the tuple apply
the map and you take the first second element of the tuple apply the
map now these are two different maps this is the map from the function
G and this is the map from the function H so that\textsf{'}s that\textsf{'}s what you
have to do so that\textsf{'}s what is here now first not pure I'm sorry I'm
looking in their own thing yeah first my flat and second one now let\textsf{'}s
substitute a definition of the Eldar flattened here which will add
a flat map one to each part of a tuple in flat magnitude to the second
part of the tuple now let\textsf{'}s look at this we can simplify actually
because this is a map in the Hunter G this is a flat map in the function
G and there\textsf{'}s a naturality law for flat map so that war holds even
for 7-1 ology because it\textsf{'}s a largest involving flat map we're not
using pure 4G anywhere so now we can exchange like this using a chirality
we do that and we get those things that we've done before so flattened
and then take first flatten and then take second so we do that simplify
to first flat map one so now we have this expression flat map of first
and flat map one flat map of second infinitum so now we have a flat
map of something with flat map inside so that can be you know if you
compare with what we have here we don't have your flat map inside
flat but there\textsf{'}s social DVT law for the moon ads if you look at the
law for flat map that\textsf{'}s exactly what it does it tells you that you
can put flatten up inside flat map or you can put it outside and the
result is the same so you can simplify it like this if you have flat
man inside flat map and you can just simply find like this and if
you do that again that so now this clearly one two oh eight nine two
two three or identical so since they're the same expression then you
social diva team or holes so the next construction is oh heavens haven't
shown this so this is generally not saying well not even if G and
H are semi magnets and the reason is remember how we discarded across
terms the G of H and H of G well you cannot do that with a disjunction
you can do that with a product but not with a son because if you want
to implement flatten for this then you would have to combine g of
g plus h plus h of g plus h into G Plus H G of G Plus H could just
be G of H all the way so there could be no G of G because it\textsf{'}s a disjunction
so it could be either one or the other so G of G of H sorry G of G
Plus H is possible to be just of type G of 0 plus h whatever the G
of H and you cannot flatten that in general so that means this construction
does not exist for disjunction of two monads to disjunction of two
more lines are generally not known are not even a semi none of them
easy the next construction is that you take a fixed type car and you
take a function from a fixed type R into a semi one on G or a monarchy
I will not give a proof for this I will leave this as an exercise
I will give proofs for most other constructions and especially from
the last construction you will see a similar kind of thing but as
I leave for you to prove so let us now consider a construction five
construction five is an interesting one not often seen basically it\textsf{'}s
making a new monad by disjunction with the type a itself I've seen
we've seen that this is generally not a monolith you have here G and
H but if one of them is just the identity movement then you can do
it it turns out you need however a fro moment for a for G does not
work with a semi mu naught so this construction is sometimes called
a free pointed factor over G it\textsf{'}s not important why it is called like
this at this point but also later when we later in the tutorial when
we talk about free constructions such as free factor or free will
nod this will be one of those free constructions for you construct
a new factor with another with a new property out of a factor that
doesn't have this property now as I said for this construction G must
actually be a full monad so it must be pointed when remind you would
point it means for a functor pointed me in the natural transformation
from identity in other words a natural transformation of type A to
G of a which is the type of pure so if a founder has a function with
the same signature as pure that what it means that the function is
pointed so what\textsf{'}s however these are theoretical considerations let\textsf{'}s
go to the code which shows how to implement the model instance for
this and to prove that it is a lawful minute so here I'll again prepare
my type our oasis for brevity the type F is just an either of a and
G of a and F F is just F of F and so now how do we define in the monad
or seven wounded instance all the easiest ways to define flatten in
order to define flatten we need to take this kind of value and return
this so this is an F of f of a written out info and this is an F of
a so how can we transform this into this given a disjunction means
where we could be given any part of it we could be given just this
or just this or this and inside could be just this or just this or
some combination because this G is an arbitrary monad so it could
be a function a container having several values of this type so this
could be one value up on the left one value on the right and so on
so this could be complicated so how do you return a plus G of any
out of this now if you are given this then you can just return the
same with no change that is easy but what if you're given this part
of the disjunction how do you extract a plus G away out of that now
what seems to be a little difficult and the trick is that actually
there is a function you can define which has this type which I call
marriage I I don't attach a lot of importance to the name of this
function marriage it\textsf{'}s just for convenience let\textsf{'}s call it marriage
and this function can be defined to define right here I'll look at
it in a second given that this function is defined we can map this
function over to the factor G and lift it into G the result would
be a function from G of this into G of G of a so we have this function
and that function is what we need to transform this and if we were
given this part of the disjunction into G of G of a now we can flatten
the G of G away into G of X and G is a mu naught and that\textsf{'}s what is
going to give us G of a and we can return the right part of the disjunction
and we're done how do we define the verge function now that\textsf{'}s a little
interesting if we're given the F of G available means were given this
we're either given a or not given G of a you need to return G of Allah
forgiving a we use pure from the G when we return the uvula and if
we're given G away we just return that so in defining this we use
the fact that pure is already defined for the modern G this wouldn't
be possible if G were a semi limit so the code for flatten follows
more or less straightforwardly then flatten on the left of this this
is FA so left of FA just returns that FA which is this type and the
right of some GF it again I'm using variable names that conform to
their type you see the type of G of F of V so if you have this then
we would have mapped with the merge and then flattened which is flat
map with lunch so we use that that\textsf{'}s how it works so this flat map
is giving you a G of B and you put that G of B in this case of GMA
you put it in into the right part of the disjunction here so this
disjunction is returned so we're done so this is the definition of
flatten for the construction definition of pure is very easy because
if you have an any just return the left of that a you don't actually
use the pure of G to define this but as I have written here in a comment
the Monad laws actually actually won't hold unless G is a full moon
ad and we have used pure to define flatten here so we have used people
of G already and that needs to satisfy the laws the F matrix standard
just a slab for disjunction if you have a left apply F right apply
F after now now just just a remark here we have been able to define
pure without using the pure function from G and this is why this construction
is called free pointed we were able to define a point for a pure function
which is where old point in some libraries without so suffer the and
constructed new frontier for this filter we're able to define the
point or pure function without using the point or pure function on
this and so that\textsf{'}s that\textsf{'}s why it\textsf{'}s called free point it\textsf{'}s a we wait
we have information enough to construct the point function without
already having given having been given this function before in the
G now let\textsf{'}s verify the laws i this is rather reasonably simple the
first law and the second law for pure these let\textsf{'}s begin with them
so first we have a pure and then apply flatten so take some arbitrary
FA applied pure to it and then apply flattened to the result now pure
over failure is just left over fade that\textsf{'}s the definition of pure
now we flatten the left when you flatten the left it just gives you
the value under the left therefore flatten of left of FA is just FA
and that\textsf{'}s the identity function as required now flat map of pure
sorry F map of pure followed by flatten that also has to be identity
now let\textsf{'}s do a F map of pure and applying it to some arbitrary FFA
I think I'm making again the same mistake as before let me check yes
this type must be F to F naught F F F F and this I also should ever
need so now this must be of type G yes good all right so let\textsf{'}s go
through this derivation first we substitute the definition of F map
which is this where instead of the function f we use pure so we write
this code but we put pure instead of F so that gives us this code
now we can substitute the definition of outer flattened which is if
you have a left than you so you see if flatten is applied to the result
of this which is either this or that so we take these things and apply
flatten to this which will be that and we apply flatten to this which
will be that because the flatten of the right is a flat map merge
all right so now we have this code now we need to simplify well what
can we simplify here not obvious well so they have this map and flatmap
and these are in the Mona G so Mona G must have its natural T law
for flat map so once you use that this law and we use that law with
F being equal to pure and the result is going to be flat map of F
and then G so pure and energy so pure and then merge is the same as
pure now this pure is our pure that we are defining for F is not the
pure virgin I always write explicitly this for the pure for G because
it is easy to get lost otherwise so pure is not for for G\textsf{'}s for F
now if we substitute what it does pure and then merge so pure gives
you any left of something emerge of the left is a monad G pure of
the content of the left so that means we have a monad G pure so pure
and then merge is the same as moment jean-pierre so let\textsf{'}s substitute
it in there so now we have this code we have a flat map of cannot
G pure and this flat map is in the mono G because I'm reminded by
the name of this variable and I can check this also with IntelliJ
was I'm sorry can you check it because it\textsf{'}s because it\textsf{'}s in the comment
so I can check it here so the this is of type when this I should have
said I should've called this da for less confusion but it\textsf{'}s just names
and variables doesn't even matter what they are but it\textsf{'}s just helping
to see what types they are so flat map is in the Mona G and therefore
we have a low flat map of pure his identity so therefore we have this
that is obviously identity so this verifies the identity laws for
a woman if you know let\textsf{'}s look at the associativity law oh yeah and
I never mentioned any naturality laws for monad if we don't check
them because the code already guarantee is not reality there is nothing
in the code that uses specific types such as a being int or string
or anything like this the code is a composition of functions it is
substituting functions into arguments that is completely natural in
the sense of natural transformation so any code like that is fully
parametric it uses functions such as swag map which are already natural
transformations by assumption as they are in the moment G so compositions
of natural transformations are any kind of use of natural transformations
will be natural so we don't need to check much rather many of this
code any of these constructions are automatically satisfying when
chirality laws but associative eg1 needs to be checked so go on to
check that law to check that law we need to compare this so flatten
off flatten and this flat and F map of flatten begin with flatten
of flatten so we apply flat on a flattened to cell FFF a so first
we substitute the definition of flatten which is this and then we
have the outer flatten on that substitute again the definition of
outer flatten which means that on the left hand sides stay but the
right hand sides get a flatten applied to them with me this is like
that so left FFA goes to flatten of the FFA and write G FFA goes into
this I can't simplify this anymore well I could like a sec before
get another flat map the flat map that could be simplified into a
flat map of large and flat map of merge I'm not sure that will help
any right now so I'll keep this code as it is and look at the other
one maybe we'll see what we need to simplify if we need to so the
other code first so I define this function which is I don't do it
now by steps this first do it right away so this function is going
to compute that so it\textsf{'}s just F map of flattened applied to an arbitrary
FFA and then we apply flatten to that so first we substitute the F
map of flatten of F F F F which is this this is a definition of F
map where we put flatten instead of the function f so now we have
this flatten and also this flatten inside go on substitute the outer
flat so that means we apply flatten to these right hand side parts
so this will apply flatten to this and we apply flatten to that so
flatten of the left something is just that something so that inner
flatten still remains here see I put type parameters explicitly so
let\textsf{'}s color compiles because I remove this it\textsf{'}s read interesting right
the types are correct and just that Scala cannot infer that your guess
would be Piper it must be and this is often the case also here I had
to put it in now notice this outer flap has been substituted already
this is the inner flap in that still remains and this is also the
inner flap them that still remains so now if we compare these to the
left case is already identical so we don't have to worry about it
anymore the right case is not yet identical it has this versus this
so let\textsf{'}s continue we need to show that these two are equal it\textsf{'}s easier
if we just stop writing all this code and start just reading one next
smaller expression at a time so in the last expression we have a map
and a flat map from the factor G so let\textsf{'}s combine them using the natural
to look for G and then we get this now let\textsf{'}s substitute the definition
of flatten and keep merge as it is we have merge applied to the result
of flatten so see this is just the code of flatten if you get rid
of merge here then it\textsf{'}s just going to be the destination of one so
now we can substitute the definition of merge on the left so merge
over Roger Bobb this weekend up simplify but we can simplify it on
on the on the right so merge of the right let\textsf{'}s look at again a definition
of marriage what it is mergers right is just the content of that right
good so it\textsf{'}s just going to give you this so that\textsf{'}s the simplification
we can do so now let\textsf{'}s compare so we were supposed to compare these
two functions we have simplified the second one and we got this expression
so let\textsf{'}s compare so now it seems to have a flat map on here of some
larger function and here we have two flat maps of merge in order to
compare them would be easy to merge these two flat maps together using
associative et law or combine them together here and if we do that
we will then have to compare GFF a flat map of blah with Jake if a
flat map of something else and that would be a direct comparison we
can drop jmf a flat map and compare those things inside so do that
basically we need to compare the two functions inside flat map inside
this construction and this is fine because G FFA is an arbitrary function
sorry an arbitrary value and so if we show that these are the same
and obviously we will have proved associativity long so then the result
so far is that we need to prove that these two functions are the same
these are the functions inside the flat map let\textsf{'}s take this function
substitute the definition of marriage and I put a flat map so if you
delete this flat map that would be just a definition of merge and
we have applied flat map on its result so far okay now we need to
compare this and this the right cases are identical the left cases
are not immediately identical but again we have here pure from model
G and the flat map of money on G how do we know it\textsf{'}s from one engine
because as a result of pure is a G of something so that\textsf{'}s going to
be a flat map also in G therefore we can use the identity law for
G and that\textsf{'}s just that function so that\textsf{'}s just going to be emerge
of a fade which is exactly this so when once you simplify this you
get this therefore both cases are identical so this finishes the proof
of the associativity law for the thunder F notice that we have used
both the identity law for G when we did this combination and we use
the associative law for G when we combine the two flat maps on the
G so G must be a full moon odd for associativity here to work he also
must be a full moon odd for identity lost to work but this shows that
unless G is a full moon that even associative et law would not call
for F so it wouldn't be an even a semi movement unless G is a full
moon that but if g is a film on that then f is also a full moon that
so therefore we have shown that this F is a full monad for G also
being a full moon and that\textsf{'}s the only construction we can show the
next construction is this one now it\textsf{'}s a G which is an arbitrary monad
applied to this type expression which is a kind of a linear function
of a type A with coefficients Z and W where Z is a fixed type arbitrary
type and W is M you know it so this is a kind of a straightforward
construction if you understand and will not transformers but I just
mentioned this for people who already know but if you don't know yet
then this is just a construction that can be shown to work so let\textsf{'}s
see why that construction works now I'm getting tired of writing up
all these type parameters all over the place like this so I'm going
to cut down on the boilerplate in the later part of this tutorial
and I'm going to just put these parameters up front so I'm going to
define all the code inside a function that already has these type
parameters and then inside I don't need to talk about these type parameters
this is just to calm down unavoidably all right so now for this construction
what we need is to apply some arbitrary Menagerie a type constructor
which is this either of Z and tuple of W and a and this allows us
to use a type alias now to define these things because g ZW and so
on are already defined as type parameters up here all right now actually
p is itself a monad and that will be an exercise line to show we have
seen parts of P so to speak we have seen this this is the writer muna
and we have seen that is either monad this is a combination of either
and writer and this is also honored mathematically speaking this is
Z plus W times a and so this is like a linear function of a which
is kind of a simple example of a moment all right now f map is defined
in the obvious way if you have a left of z you don't you don't change
it remains left of z if you have a right of tuple w a then w doesn't
change you transform a now we can write a cat\textsf{'}s monad instance if
we feel like it cats monad is my own typeclass that has flat map and
pure and that can automatically export your model into cats how did
you find Flattr Wallace is a little maybe come ok but it\textsf{'}s it\textsf{'}s very
straightforward for P you don't do anything with the left and then
you map on the right because on the right you have an a so you have
some W 1 a 1 you take f of that you get a P of B then you match that
if it\textsf{'}s a left I mean again you return the left if the right and you
now you have to double use but you combine using the semi group and
you have a a 2 which is actually a B so it should not be called a
2 but snow nameless you call this B to be more clear the pure function
is defined clearly us is a right of every team annoyed value of W
and they that you're given so that\textsf{'}s clear but just like the right
terminal and either o the flattened defined for P I'm writing this
code here because we will need it for reasoning so let\textsf{'}s look at how
it works so we have this type expression and we want to convert it
into this how do we do that well if we have a Z so see looking at
this type expression means that we can have a Z or we can have a W
times Z or we could have a W times W times a because this is just
like school algebra so you just expand parentheses and plus and times
symbols distribute so if you have a Z or if you have a W times Z you
cannot possibly return on a T so you must return you see here the
other case is that we have W times W times a so you can return an
A and you combine these two w\textsf{'}s so that\textsf{'}s what this chrome does were
consistent done so we have flattened and F map for P which I explicitly
defined as flatten P and F map BMI also you find a flat map for people
let\textsf{'}s not let\textsf{'}s see how we can define the flat map and flatten or
something for F now for G we already have flat map and everything
we just want names for them for convenience so I you find them here
again with these names I'm using already defined called from a functor
and the mall and typeclasses for G so that\textsf{'}s just for convenience
because I we need to reason about these F map and flatmap G and so
we want to have these functions but of course we can't reason about
these much because we don't know what these actually do this is an
arbitrary monad so we don't know what code is inside lease all we
know is the properties so we know that this is a lawful monad or semi
unit so it\textsf{'}s the same story again we will see that to prove associativity
we don't need the pure from G and we don't need the pure when we don't
need the laws of identity for G we only need the social tivity of
G and so if G is a semi wanna this will be Samuel F G is a film owner
than F will be also a full moon on the F map for F is defined by doing
a functor map on the function that takes a function P map because
that\textsf{'}s just a composition of two functions so f is defined as a composition
of G and P so it\textsf{'}s a composition of two maps map of that but let\textsf{'}s
write down the short notation which will be quite helpful so f map
f is f map G of F of F of F or we can write it like this which is
shorter and let\textsf{'}s see if we use that in reasoning in a certain way
so then we can define a function instance for g sr e 4f by composing
my factor instances and we can define pure for f so this is a pure
for F I should have probably called it a few F just so that we are
not confused let me do this so pure for F is defined in the usual
way we take the pure of G and we apply that to this which is a pure
of P right when you find pure of P in here so pure of F is just your
F equals purity followed by energy just like F map is like this curious
like this let\textsf{'}s see if this will help us reason about it so now the
interesting part comes I need to define flat for this functor so the
function f is G of P of a and so flatten needs to transform F of F
of a into F of a so f of F of a is this and we need to flatten it
into just one G and one P so we have two Gs and to peace and they
are interleaved so somehow we need to transform that and we could
transform this if we change the order here of p and g players if we
could transform that into this type then it would be easy you just
merge this flatten this into one G when you flatten that into one
P and you're done so what you need is to define this so-called sequencing
function which changes the order in the sequence of applying factors
so it takes P of G of whatever and returns G of P of that and this
function does not always exist for all kind of funk stars PMG you
won't be able to define in general such a function but this function
will exist for a specific factor T which is defined specifically by
this type expression so for this function key and front a few other
such factors this function will exist for the function changes the
order and let\textsf{'}s define it now how does it work so it\textsf{'}s supposed to
take a PGC and return this so well P is either the only thing we can
lose to match so what is the result of matching if we have a left
of Z then we should return a G of something well the only thing we
can do obviously is use the pure of G to return the left of Z because
there\textsf{'}s no no way for us to return any Ace or double use in this case
if we are in the right then we have a G actually and we have a W so
let\textsf{'}s see what we can do with this we can take this GC and map over
it and we can add the W to that see what\textsf{'}s inside it the result will
be a tuple of WC we could put it into the right and that will be of
type P of C and so now we have G of G of C exactly as we need so this
is a little involved but that is a very important function without
that kind of function was no hope to define this construction for
a composition of two funders being imminent so seek this function
seek is a transformation between functors P of G \& G of K and since
it\textsf{'}s it\textsf{'}s you only uses natural transformations and fully generic
code fully parametric type C is anything we don't use any information
about what C is then it\textsf{'}s a natural transformation we don't need to
verify the natural anymore and this is a naturality war the functor
on the left is PF Geneva function on the right as G of since of maps
must be in the first factor and F maps in the second factor that\textsf{'}s
a natural G law that exchanges the order of F map and your natural
transformation so I'm not going to verify this because of the permit
tricity theorem but it could be done there easily of course in the
same way as we verify all these other laws just write down the code
of F map PF map gene so one of you transform and substitute and simplify
and you get that these two functions have exactly the same source
code and so that\textsf{'}s just a waste of time to do that because the chromaticity
theorem guarantees naturality but you could do it so now let\textsf{'}s define
flatten for F we define it like this it was a monad G flat Maps it\textsf{'}s
a flat map from G which takes a function of complicated type so let\textsf{'}s
look carefully what it does we're supposed to do F of F of it now
F of F of a is actually G of P of G of P of a and if we flatmap with
something then something must be of type P of G of T of a going to
something so therefore the inner function must take P of G of P of
a and return something well what should it return well it should return
G of something because that\textsf{'}s what flat map does that map takes a
function from some X into some G of Y and the result will be G of
Y now the result must be this therefore this function this inner function
that we are not yet ready to write this function must take this type
and finally return that type so I'm showing how I got got this how
I derived it you see I'm completely looking at types and I'm not guessing
I'm just saying flat map must take that type and that\textsf{'}s what it should
be and it should return that type in order to return this now how
do we get from here to here obviously we use the seek which will interchange
p.m. G into G and P so that will be this and then we flatten P but
flattening of P must be done under a layer of G so therefore it is
F map G of flatten P and once we do that we're done so therefore the
type of this inner function must be this and G of flat map of that
type would be a function of this type exactly as we need take some
time to check this so that the types are correct a flat map the right
type parameters and if you once you have checked it it will see why
it must be like this this is flatmap must have that signature G of
X going to G of Y having a function X - G of Y as an argument and
so X is this why is this and then if everything works so finally this
is the code I'm just writing what I have seen what would I have done
here secret random f9g faculty so this little piece of syntax is necessary
for Scala {[}Music{]} for some reason I think it won't compile I had
trouble compiling it um without this but this is basically saying
that this is a function the seek is a function it\textsf{'}s unnecessary parenthesis
but let\textsf{'}s put them in for clarity all right now the short notation
for this function would be useful for reason is that I take flatmap
in the G mu not of this composition and you can use natural T for
flat map G to rewrite it like this so now actually we are in a very
good shape we don't need to write code because the short notation
works well enough now in the previous examples I didn't do this and
I wrote the code but let me try to avoid writing code I could do the
same as I did before just keep rewriting the code but let me see if
the short notation works maybe it will work on up to a point alright
so in order to verify the associativity of all we need to verify that
this is equal to this so let\textsf{'}s verify that F map F of flatten F followed
by flattened F so we just substitute this definition of F where F
which is this and then substitute the solution of flatten F which
is yes flat map G of seek followed by F map G of Kelantan P so I just
put it in here and put it in here and here I now look and try to simplify
these things so how do we actually simplify anything like this just
looks very complicated the way to do it is to try to understand what
parts of these things belong together to be simplified so for example
F map G and F a level G they can be manipulated because they're in
the same factor and there\textsf{'}s naturality law with interchanges flat
map and F map or flattened and F map it has a much reality law but
only in the same factors so flat map P does not have any natural ality
law with F map G so we have to pull these things together somehow
in order to in order to simplify anything so for example I want to
use natural 'ti of seek how do how can I use it the only way I can
use it is what I have F map P of F F of G of some F immediately before
seek and here I have what I have seek here and seek here nothing is
immediately before it so somehow I want to pull this thing together
so that it\textsf{'}s immediately before seek and then I can achieve maybe
some simplification using neutrality for seek so how do I pull that
together well I have this I have this thing F map of this so let\textsf{'}s
see if we can first use this naturality which is f map G of something
and FLL G of something else appears at higher level we have F map
G of all this and F LMG of this so how do we pull this together we
use this naturally G law and we apply it so we apply this law and
we get FLNG of a big thing so that\textsf{'}s the first step so inside is going
to be all this stuff without the second F of energy because the second
of all energy is going to be out so the result is that we have one
big FLNG so by combining this and this {[}Music{]} using parentheses
here somewhere just to be completely pedantic one two three two three
two one zero that\textsf{'}s right all right so now we have combined this F
map G and F LMG into one big ecologic the result is this FLNG of this
so now does this look like seek of and although to the left of seek
I have {[}Music{]} F map PF mataji of something does it look like
that to the left of seek I have F naught G of something but F map
P is over there it needs to be immediately here below to the left
of this so how do I get that well if map we can split so f map of
composition is f map of this followed by f map of that so we can split
that in the factor P the result is this F map p f mappy seek ethnology
great now this is what we wanted we wanted to pull together C and
F map P of F map G of whatever now we can pull this on the other side
of seek by using that reality of see so much relative seek is this
one and using this law we pull it and the other side of seek and also
it exchanges the order of F map J and P but that\textsf{'}s okay so the result
is this now that\textsf{'}s examine this we have F naught G F mataji let\textsf{'}s
pull them together maybe we get an F map G of this now this is a social
dignity law for B it\textsf{'}s equal to just flattened P followed by 20 people
so this is a social activity law for tipping the result is their fullness
now let\textsf{'}s pull it apart and we get F map G under F L M G so then we
can pull that out maybe it\textsf{'}s not clear that this will help but let\textsf{'}s
just see if that helps because we still haven't seen the other expression
so maybe the other expression will be similar to this all right so
at this point there is nothing else we could usefully simplify let\textsf{'}s
look at the other expression the expression is lists so we substitute
the definition of flatten F and we get this so now how can we compare
this code and this code well both of them end in the same way that\textsf{'}s
good but this part is one big flat map and this part is so I have
F map flatmap so we need to combine this into one big flat point to
do that by using naturality and associativity of G we can do it so
naturally allows me to pull this inside the flat map which gives me
that associativity allows me to pull the second flat map inside the
first part map which he gives me this so the result is one big flat
map with this followed by this piece which is the same as that so
don't want to compare you could say except for what\textsf{'}s inside the big
flat maps and both of these functions have the same type and look
at the types yeah quite complicated but I just want to write down
what we had here F may have seek holiness here after my PF a flat
map G of seek followed by seek followed by this I just write down
Scala code for this in order to make sure that everything is still
like checked and correct so this is that now a short remark here about
rotation all these computations I've done here I've never mentioned
any types as if the types will always match whatever I do why is this
why don't I need to check at every step that all these types are correct
no the reason is that these functions are polymorphic they will adapt
types to each other as long as types can match they will adapt as
necessary each of our laws is a fully polymorphic fully parametric
type function and so if the argument type ins to be changed it can
be adapted automatically if will never leave their type mismatch whatever
you substitute if a function is equal to another is substitute maybe
the type needs to be adapted but it can be always adapted because
there\textsf{'}s always some more general type for which the laws hold which
is the way we usually write them so for example for this law this
goes from F of F of F of a to f of a but a is completely arbitrary
so as long as you put that into any expression a might adapt to something
and because it\textsf{'}s an arbitrary type type but adapting won't ever break
any types so the laws hold for the more general types compatible with
these function signatures and that\textsf{'}s why we don't actually need to
check any types while we do this kind of manipulation so now let\textsf{'}s
see now these two functions is not obvious that they are the same
there are quite different so first of all it starts with seek with
a different type parameter and this is the seek under F met P FLNG
it\textsf{'}s completely unclear whether this is the same and it\textsf{'}s probably
not the same as this you follow it by flanton P under F map G and
here the flatten PF my G is at the end and so it\textsf{'}s not obviously these
functions are the same so let\textsf{'}s maybe write the code for these functions
actually we're maybe trying to evaluate them on some on some values
because it\textsf{'}s impossible to simplify these expressions further in order
to to show that they're equal simplify what I mean is that it\textsf{'}s impossible
to simplify by using laws of flat happens fmg symbolically like this
and not actually getting inside the code of seek for example so these
functions are equal but only for the specific code of seek that we
defined so that\textsf{'}s why we need to now go a little deeper into the code
so the arguments of these functions are P of something because of
that the argument can be either left of Z or a right of that so let\textsf{'}s
apply these two functions to a left of Z and then we apply to these
functions to a right of this and see what happens so if say X is left
of Z if we substitute the definition of seek then seek of left of
Z where it is assumed to be of of that type of this type so Z left
of Z is still of this type then the sick of it will be by definition
of sick if you substitute into the code it will be this and flatten
of it is just left of Z so you substitute the flatten P and again
that and so if we try to evaluate F 1 which is sick followed by F
map G or flatten P and followed by flat map G of Z so what happens
first we do seek so we get a pure then we apply flat map so we apply
a F map G of flatten so inside this pure applying F map means applying
the function to this so we apply flatten to this we get left and then
we do a flat map of seek on pure and F map of seek on pure is just
sick applied to this left of Z which is this so sick of left of Z
is ma not be pure of left of z f2 on the other hand gives me a trivial
result because this F map doesn't change anything because I have a
left of Z so f map P is identity on that so I have left of Z then
I have seek which leaves me sick of left of Z which is this and then
I have f map G again a flat of P which is the same as what we'll just
complete it and so it\textsf{'}s both f1 and f2 evaluated on left of Z will
give me the same result so that is the first case now let\textsf{'}s look at
the second case that\textsf{'}s going to be longer if X is the right of this
then we need to compute think of it which is going to be that after
seek we compute F map G and that means we are we're already inside
map in the G function so we just add another map in the G factor so
we do that the result is we can combine the two maps into one and
first we apply this to some PG and then we put a flat mu P on top
of that so that\textsf{'}s the function we get therefore {[}Music{]} finally
f1 so if one is seek than this and then flat map of seek so add that
we can put in a map and flatmap by that\textsf{'}s reality because they're
both in the g-factor and when we get seek applied to that that\textsf{'}s the
result now this kind of thing is the result of F 1 of X now for F
2 of X we first compute a flat flat map G of seek under F map P which
means that well for the functor key F map Maps the right and it leaves
W unchanged that map\textsf{'}s the value of x a so then we get this and then
we do a flat map of seek on that finally we apply a seek so let\textsf{'}s
go back to definition yeah so we have done this so far we apply seek
to that then we have to apply this so it\textsf{'}s saying that we apply over
here okay ply seek to that we and get this finally we apply F map
of level B to this then we just tack on document flooding because
this is a all these flat maps maps and maps they're all all analogy
functor so let\textsf{'}s pull out into one flat map using naturality begin
this so now the result is we have F 2 and F 1 of X computer F 1 of
X is this F 2 of X is is that both of them have the foreign GPG dot
flat map of dois so we need to compare just those functions this functional
body let\textsf{'}s compare them one is this and the other is that now it\textsf{'}s
kind of hard to compare this because PGA is arbitrary W is arbitrary
what can we do so what\textsf{'}s pattern match on PGA and well I should have
written code maybe but I always let\textsf{'}s just substitute values and see
if it\textsf{'}s working better so PGA is either left Z or is the right of
this with some W 2 and G if it\textsf{'}s a left z then let\textsf{'}s look at let\textsf{'}s
look at that so flatten of this would give you a left z but can't
give you much else you couldn't possibly give you a right of anything
because it doesn't for the right you need you know W so you have a
lefty so sequins LLC is pure G of Z and so we have pure J of MZ as
a result for f2 we have so we'll look at this function where PGA is
left z c curve left is pair G and then pure G of left GU map whatever
you want to map the Z is not going to go anywhere it\textsf{'}s no it\textsf{'}s not
going to change so the result is this so therefore for the left these
two expressions are the same so now it remains to compare these two
expressions if PGA is right of something so we compute that and the
result is that here we have the flattened p of the right of this and
here we have to combine W and W tube using a semigroup operation the
sick of that is going to be equal to this and for F 2 we perform similar
computation and we basically again have the same expression because
the flatten P works like that and that finishes our proof so I tried
to make it shorter so part of the way I was just doing symbolic computation
at the level of factors and units with no specific code so this would
be general but after this point I could not continue the fully general
computation I had to put in a specific code for seek and flatmap flatten
P and so that\textsf{'}s at this point maybe it will be sure to just start
writing code and compare the code for these two functions but I found
that if I first substituted left it was very quick and so onion it
this way the next construction is this one it\textsf{'}s a very important construction
because it\textsf{'}s recursive function f is defined recursively and it gives
you a monad for any functor G a and G does not have to be a melody
itself so this is the only construction here where get a moon ad out
of a arbitrary factor rather than out of an arbitrary another one
odd but because you get a moon ad out of an arbitrary factor so to
speak for free remember it\textsf{'}s called a free monad over G I mean mentioned
that there are constructions called free constructions that give you
properties for free well for free means you don't have these properties
in the data that you are given and you're just creating them in some
way out of the structure of new functor but in a later tutorial I
will explain the free constructions in a more detailed presentation
so for now it\textsf{'}s just a name for this construction so let\textsf{'}s see how
it works now we have seen this construction in the examples and this
was the G shaped tree functor so the G shaped tree in other words
a tree with G shaped branches that\textsf{'}s exactly this construction so
the tree has either a leaf with a single value of type A or it has
branches inside a functor G so the function G distribution describes
the shape of the branches and under it each branch there\textsf{'}s another
tree again of the same recursive shape so let\textsf{'}s see now how this how
this works we assume an arbitrary function G not Superman I said yes
so it\textsf{'}s any function G wasn't this functor doesn't have to be itself
Amana I define this function construction seven just so that I have
fewer things to type now we can't define the type alias for this because
it\textsf{'}s recursive so I have to define a case class with a type parameter
and that forces me to have a name for this inner part but that\textsf{'}s not
going to be used much so this is just a plus G of f of a how do we
define flatten and F map which thing as before it\textsf{'}s the tree the G
shaped tree so f map on the leaf it\textsf{'}s just a transformed leaf F map
on a branch is the same F map recursively applied to each value in
the branch container so G works as a container but may have one or
more values and that\textsf{'}s the branching if it has more than one value
then you have several branches the flattened works by keeping leaves
as they are so if you have a tree of trees and the leaf of the tree
means you have just a single tree in return that tree if you have
a branch then you need a map of flatten so this recursive case is
going to be the same for all these of these constructions this code
cannot be written otherwise they have to map over this functor with
a recursive call to the same function pure is defined by just returning
a tree having a single leaf that carries that given value let us verify
the laws this is the identity second identity law we just substitute
the definitions again so to verify this law we need to take some arbitrary
FA apply pure to it and then apply flatten to that result so let\textsf{'}s
flatten of pure of F a substitute the definition of pure will get
F of left of F a substitute definition of flatten what\textsf{'}s FA it\textsf{'}s against
identity and let\textsf{'}s compute F F map pure of flattened but actually
it will be may be helpful to compute flatten the F map of something
followed by flatten is flat map where definition so let\textsf{'}s compute
that function first flat map so how do you do that so it\textsf{'}s flattened
of F map of F of some arbitrary FC what\textsf{'}s the definition of F map
is this matching with recursive cursive match and when we substitute
the definition of flatten which means that we apply flatten to these
right hand sides of this match so this remains the same the right
hand side is flattened flattening this gives you f of C flattening
this gives you that and we can replace F map don't flatten because
this is map of this dot map of this which is equal to dot map of this
followed by this and we can just replace that again by a full line
because that\textsf{'}s the definition of you follow so that\textsf{'}s going to be
the code for a fella so again just your cursive keys is always the
same we just use different functions of your map that\textsf{'}s always the
same alright so what is now a full MP rifle unpure is this f LM Puran
must be in apply this to arbitrary F a substitute the definition of
a for Lam which is this put P you are instead of F and so then again
this now pure of C is f of left of C by definition so this first case
is just identity by definition of pure the right case is this now
if we have proved that it is identity on the leaf now we have a recursive
case now we cannot directly prove that it is identity because we don't
know what that is we haven't yet shown that the right case gives also
identity so we need to prove this by induction induction is on the
structure of the tree if we are in the leaf we have proved that it
is identity if we are in the branches and for each branch we've already
proved that this is an identity then we need to prove that it\textsf{'}s identity
here in other words we need to we can assume that the is identity
when we recursively call that function once we assume that then it\textsf{'}s
obvious just map identity so this is f of right of GFC and so that\textsf{'}s
clearly identity so assuming inductive assumption which is that this
function is equal to identity on any of the sub-trees we can prove
that it\textsf{'}s equal to identity on the whole tree that\textsf{'}s how all these
proofs are going to go for recursive functions that\textsf{'}s the only thing
you can do you assume that the recursive calls to your function already
satisfy the property that you want and then you prove that\textsf{'}s the inactive
assumption then you prove the step of the induction alright so this
proves the identity laws let\textsf{'}s now prove the associativity law so
she'll give it a law which is this you know let\textsf{'}s write down the code
for these functions apply this function to an arbitrary FFF a of this
type substitute the definitions we get this so the left case is that
the right case is kind of complicated so we can substitute this into
into the first map so that will be flat and followed by flat which
is the same as this function so now we can therefore write the code
like this so you see all of these functions are always going to have
the right case using exactly the same code so that\textsf{'}s kind of a boilerplate
isn't it there is a way of getting rid of us but it\textsf{'}s more advanced
these are called recursion skills and I will talk about this in a
different tutorial but for now we will just keep writing this boilerplate
each function will have a second case of this of this sort now flat
map flatten is the second function we need to compare with this one
we have substituted again flat map instead of this composition so
flat map of flatten applied to an arbitrary FFF a what\textsf{'}s substituted
definition a flat map which is this and then we get if we rename FFA
to instead of C then we get the code that\textsf{'}s exactly the same as this
except for the name of the function and the recursive call is of course
to the function name differently so if we rename the function rather
than we can't distinguish the two functions in the world so it means
that their code is identical so this shows the associativity we have
not used any properties of G other than map so all we have here is
this map from G we have not used anything else we have concatenated
the two maps into a single map that\textsf{'}s a property of a functor and
the composition law we have not used any other laws for G and so therefore
indeed we have produced a monad out of an arbitrary function G the
next two constructions are in general only semi winnette constructions
so they do not yield full o'Nuts the first such construction is the
G shaped leave and D shaped branch tree which we have seen before
so leaves are of shape G and the branches are also a shape G that\textsf{'}s
a tree like this but we'll see it cannot be made a film or not only
a Samana so what\textsf{'}s looking this construction will show that it is
not a Mona so how well let\textsf{'}s define first so we define again a case
class with type parameter it\textsf{'}s a recursive type because it uses F
inside itself so it\textsf{'}s on either leaf and so we have G for functor
G describing the leaf and the factor G describing the branches imagine
that G is a pair of a a then this will be a leaf consisting of two
values of n this will be two branches F of F of F consisting of two
new trees so that\textsf{'}s either two values or to introduce notice that
the shape of this tree so the flattened can be defined certainly and
by redistributing leaves in two branches so if you're on on the left
and you have these leaves then you just these are leaves so you have
G of F of a so this is of type G of F of a and that\textsf{'}s what you need
to return can return the right of that and you are in here you're
in the right part of the either and so you can just immediately return
that so essentially you're redistributing G leaves into G branches
you have this option because the tree has this shape the the right
case is just a recursive case doesn't do anything it just repeats
the same operation on the branches F map again same thing you map
over the leaves and you do the same operation on all the branches
now I will leave it to exercise 15 to show that this is associative
the proof is somewhat similar to associative 'ti of the ordinary train
but I will show that you cannot make this into a full minute here
if we wanted to do that and we defined pure well we need obviously
a methodology in which which makes you some valium well suppose we
had one maybe you can always have a pure from the free construction
if you have any any factor say H that doesn't help here and you take
an either of a H and that has a pure and just a pure rule on being
left away so that\textsf{'}s a free point to do for that construction you can
always so that\textsf{'}s it you can always do that so let\textsf{'}s imagine that G
has a pure method whatever it is then we can generate G leaves by
using that method and we can define pure we could also generate G
branches like this by doing recursive call of the pure but that\textsf{'}s
of course infinite recursion so that\textsf{'}s not that\textsf{'}s not great that\textsf{'}s
not it not great at all or we could terminate that recursion at some
point for example we can do a pure of a which is this one-step pure
generating leaves and we can put that into branches into another peer
so it\textsf{'}s pure of pure base because it\textsf{'}s kind of a two-step regenerate
any branches but each of these branches is a leaf itself so you could
do this you could imagine defining pure in a number of ways and none
of this works here is why we need to have this Lord some flatten of
pure needs to be identity on an arbitrary FA of type F of a so flatten
of pure if we substitute definition of pure is like this I'm substituting
this definition the first one the most straightforward one and the
result is that flatten will redistribute the leaves into branches
and so the result of this is always going to be a right of something
there\textsf{'}s no way this could be equal to FA for all FA what if I face
your left that\textsf{'}s it you can't do it it\textsf{'}s not going to be under the
identity function now no matter how you implement pure whatever pure
returns it to be turned left it could return right after flatten you
will get our F of right of something so there\textsf{'}s no hope that that
could be an identity function because it will never return an F of
left of something and it must do that for some FA like let\textsf{'}s say for
this kind of a thing and so already we see that the left identity
law cannot possibly hold for for this truth no matter how we implement
peel one of these implementations we'll have a look all right so I
keep you busy with the exercise that will show a social duty of this
some walnut and only one construction is left this construction is
unusual because it gives you a mu net out of an arbitrary contractor
or a semi Monad out of an arbitrary contra funder and a functor similarly
to this construction a full monad is only obtained when G is absent
so this is a construction that gives a full moon of the results are
different from those in the construction we have seen before those
in construction - or here you could have a moon out where G is a moment
not just an arbitrary factor here you cannot have a moment even if
G is a moment we will see how that works to define this construction
we start with semi Malad so assume when G is an arbitrary factor H
is arbitrary contra factor and we define the type F as a function
type going from H of a to the pair of a and G of a we will have to
define a filter instance for F for this it is convenient to find to
define a function instance for this type instructor which I'll denote
F map a G which is what we've seen before in the previous construction
in the construction - this is the same type constructor now F map
F is defined like this so did you find it we need to take a function
f going from A to B and arbitrary value F a of type F of a which is
this function so f a is this function and we need to produce F of
B which is again this kind of function will be instead of a so to
produce that we write a function expression starting with HB and then
we have to return here a tuple of B and G of B we do that by using
F map in G that returns us a tuple B of G of B and we apply that F
map F on some tuple of a G of a which we obtained by calling this
function on em h way how do we get an HIV when we have H of B we use
contra map on H of B using function f so contra map goes in the other
direction takes a function of a to b and transforms h of b to HIV
so in this way we obtain the correct type and there is no other way
of doing it now how do we can compute flatten well we need to define
a function that takes an arbitrary f of F of a and returns F of a
how do we define that well to return F of a means to return a function
of this type so we start the code by taking an argument of type H
of a and we need to return now a tuple of AGOA we have a function
of this type what we need is to return this tuple of a G of a so clearly
we have to call this function on something there\textsf{'}s nothing else we
can do we cannot just create a tuple of type a G of a out of no data
so we have to call this function but on what argument we need to get
an argument of type H of F of a in other words of this type and suppose
we can do that then we call F F of F FA on this we get a tuple of
this kind well then we could discard the second part of the tuple
and we get our F of a as this as as as required so it reminds just
to get somehow a value of this type so how do we get the value of
this type well we actually have a value of HIV so what we need is
to produce H of F of a using HIV while using HIV because they have
no other data at the moment so let\textsf{'}s think about this so we can use
contra map on H of a to get H of F of a and the control map would
need a function of this type fly control map there\textsf{'}s nothing else
we can do with HIV H of a is a value of an arbitrary control function
H we don't know anything about it and we the only thing we can do
is to use control map on that control factor and notice we are trying
to do nothing special with these types will not trying to match on
types or use reflection to see what that H is we just use information
that is available which is that each is a contra factor and G is a
factor and since we keep doing just that the result will be a natural
transformation so we're not doing everything special with specific
types always fully generic in our type parameters okay so how do we
get the function of this type of F of a going to a is a function that
can be written like this it takes F of a and produces an e so how
do we produce an a well we must apply F of a to something to produce
an e F of a is this type so we need to apply F of a to some a tree
and we have one this one so we apply F of a to HMA we get a to go
NGO a we take the first part of the tool and that\textsf{'}s an e so that\textsf{'}s
the function we need here on which we use contra map I write out the
argument the type of argument of this function for contra map to compile
because if I don't Scala will get confused we're done with this so
we now have defined a value of type H of F of a we can apply FFA to
it and get this and then we take the first part of the two ball and
that\textsf{'}s an F we apply that to H a and we get what we need so this is
a bit convoluted but this is the correct way were the only actually
way of doing this or implementing the type now let\textsf{'}s think about this
a little more and think about how we can simplify this flat map flatmap
or flat pack flatten well this thing is a function that takes HIV
and returns hm f of a and it turns out that this is a function we
will use repeatedly so let\textsf{'}s define this function separately with
the name I call it insert f because it inserts a layer of F inside
a layer of H which can be done with this specific type and it just
usually cannot be done like this you cannot insert something into
another type constructor arbitrarily but it is done as we have seen
with these types so I just copy this inside the code here and then
I can write the definition of flatten in a shorter way as this f f/a
instead of H if a I use this so then it\textsf{'}s clear this is a function
of H a so the argument of AJ is used twice because of this it\textsf{'}s hard
to rewrite it in a point free style point free style means we don't
write arguments of functions we just write function compositions so
if we didn't have this application then I would be able to write it
in a point free style as FTL equals 50 n takes FFA and the result
is a function that takes a chain applies insert F first to H a let
me let me write it in a nice way I'm looking for the functional composition
symbol this one copy it over there so first we apply insert if tha
then we apply ff8 TJ and then we apply the first element in the tuple
extraction but actually this still has to be is still a function that
needs to be applied to each e and there\textsf{'}s no nice way of writing that
down so can't really write fully point freestyle and also a fully
point freestyle would be the FT N equals something I'm not f TMF FFA
or something and we can't do that is that the phase used like this
inside it\textsf{'}s very hard probably you could invent a notation for this
will probably not be very useful for reasoning about it so that\textsf{'}s
I'm not sure if anyone has an invented notation for the point freestyle
for such things and if so it\textsf{'}s probably not very useful for reasoning
but in Haskell ecosystem there is a tool called 0.3 that transforms
functions into a point freestyle the result of that tool not always
eliminating so we tried we don't see how much much useless let\textsf{'}s not
do it so we'll keep it in the code let\textsf{'}s now verify the associative
a table so to verify a social deity we need to compare this with this
so let\textsf{'}s define the first function which is a composition of flatten
and flatten this function takes an arbitrary FFF a first it applies
flatten to that so which is a flattened with the type parameter F
of a I'm copying now the short definition of flatten and I rename
h8 of HF a because that\textsf{'}s the type of that other than that it\textsf{'}s the
same code now I apply flatten to this code which means I write again
this expression but instead of FFA I take this this function so this
function is applied to insert F of H a so that means instead of this
I have insert F of H a so instead of H F a I have insert F of H a
so I just substitute I write this and instead of HFA I write insert
F of H a so then the result is this I have now insert F of H a and
insert F of insert F of H a because I substituted h fa into here the
second function well there\textsf{'}s nothing here we can simplify so at this
point let\textsf{'}s keep in this way we'll see what we need to transform when
we look at the second function so the second function is flat map
of ATM of F T n followed by F T n so we take F F F a we first applied
flat map of F T onto it which is sorry not a flat map with F map so
F map of f TM is obtained by substituting the definition of F map
which is this so we copy this code in here and I just renamed it your
face so that it\textsf{'}s easier to be substitute later now we apply f TM
to it we get f TM of that I just copied here substitute the definition
of f TN which is the same as the substitute this into this expression
so we have h a goes to this this H a comes from the definition of
F T and I have TN and returns a function that starts with H a and
returns this and instead of F FA you insert the function to which
you apply flat map sorry flatten so result is this so this is instead
of FFA in death code if you do that you get this so now it looks like
can do very much except try to substitute the definition of F map
a G now look we have F map a G of something dot underscore one so
let\textsf{'}s see what earth map AG does when we do underscore one after it
so actually this can be simplified if you look at the definition of
F map AG it returns a tuple so dot one of it is just this in other
words applying F to the first part of Ag so that\textsf{'}s what it is applying
F to the first part of Ag now we can simplify F map a G of this function
instead of F and this instead of a G so this is a G dot one to which
we apply this function f teen mystery of F and then we still have
to apply the result to AJ now see I'm very careful I'm just copying
the code and inserting I'm not checking any type stuff actually I
could I just uncomment this and save scholar complains well it probably
complains what it complains about too many arguments oh yeah because
I have this this thing let me comment this out right this is not valid
scholar syntax right so this has a correct type and restore the comments
as they were before so by just putting this into the Scala intelligent
code I check the types that\textsf{'}s how I did it so each of these would
was type checked before I come in the default so now it remains to
substitute the definition of FTM so we have FTM here as a shorter
form with two arguments FFA and AJ so let\textsf{'}s just list so we put this
and substitute instead of F F F F F n this and AJ AJ so we just put
that there and we get this now let\textsf{'}s compare these two expressions
HHA sorry fi cafe of something dot one of this the one of that so
that dot one of blah is the common element here F F FA of something
is common element so the only difference is these two pieces the in
self of NSF and NSF come from AB flat so these two are different so
let\textsf{'}s see if they are transformed into each other if we put more effort
both of these expressions have type H of F of F of a because we insert
twice here and here we insert once and then we'll come to map so let\textsf{'}s
show that they're always equal and then if we can show that we're
done we show that these two expressions are always equal this one
in this one so it remains to compare these two so let me define just
functions that take AJ and return this and the other function will
take AJ and return that no no no I'll transform the code of these
functions I'm defining them just so that I can easier easily check
types without repeating all that so now the first function is this
let\textsf{'}s substitute the definition of insert F and we get F FA of this
underscore one of this underscore one remind you the definition of
constraint F is a shape control map of this we do a cheek contour
map of this contra map of that which can be contracted to a single
control map with composition of these two functions so that\textsf{'}s what
I did here combined to cause and the result is this we have this expression
let\textsf{'}s try to see what happens in the other one we have this let\textsf{'}s
substitute the definition of insert F which is this one now let\textsf{'}s
compose the two contra maps so we need to compose in the opposite
direction so we first apply this function and then we apply this function
in this case the first function is flatly and the second function
is is this one apply a chain not one so then we have this contra map
first we flatten take some arbitrary F of F FA flatten it first and
then apply this function to the result that results in this function
then we substitute the definition of flatten and that is this short
definition so now we can compare these two expressions and we see
that they are identical you see I can probably remove this yes let\textsf{'}s
type a notation I can remove and I can just rewrite this for syntax
so then they are syntactically identical so this shows that these
two expressions are identical so that concludes our proof of the associativity
law that\textsf{'}s to say it\textsf{'}s a semi mu not the only thing we have used is
a contra map property and the map property for G when we defined F
map a G so f map a G is used to define F map for our constructor F
and confirm map is used to define flat so that\textsf{'}s the only thing we
define we used to define flatten and F map for this type constructor
so then it becomes a semi moment and we have checked the social activity
so now let\textsf{'}s see if this can be defined into a full moment we'll show
that actually this cannot be done unless G of a his unit so in other
words we can only done it in that way oh how to show that well first
of all how can we create a pure for this F when you take an A and
we need to return a function it takes H of a and returns a tuple of
eight and G of a well how can we return a tuple of a and G of a we
have an eight we need a G of a also the control factor H of a is of
no help it cannot give us any values of type A or of type G of F so
we must ignore that contra factor argument of type H a we have to
ignore that argument and we return a tuple of le and then we have
to have some function like pure G of a that returns a G of a given
a name in other words we need that function in order to define pure
flotsam and imagine we have that function in other words the factor
G is pointed that\textsf{'}s what it means to have that function a natural
transformation with this type signature so imagine that the font of
G is pointed can we define a full monad for the type constructor F
let\textsf{'}s see we can define pure with the right type signature that\textsf{'}s
for sure let\textsf{'}s check the laws identity laws is that pure followed
by flatten is identity so let\textsf{'}s do that take an arbitrary FA apply
pura to it and then apply flat into the result but substitute the
definition of flattening acting on pure so that will be this now pure
of a PHA is something that returns a function that ignores its argument
so we can ignore this and the first part of pure of the fame of something
is fa so therefore this is a che going to FA of AJ so all this goes
away this returns a che so H sorry this returns FA so this becomes
FA of AJ so now the code is like this and the function taking page
a and returning FA of which is the same as the function FA so we don't
we could rewrite this as simply effect so that is the left identity
law so that holds let\textsf{'}s take the right identity law its F map pure
and followed by flatten so we take an arbitrary FA we apply F map
Puran to it and then we apply flatten to the result and let\textsf{'}s write
a tray right here for simplicity and so we'll apply this to AJ what\textsf{'}s
now transform this expression this expression we substitute of the
diff the definition of flattened FFA HJ where FFA is this so that
gives you this piece followed by application to NSF of LJ dot 1 over
J so that\textsf{'}s not now let\textsf{'}s substitute the definition of this in here
where F is puree FA is FA and HB is this so the result I'm just going
to take the code for F map which is up here and substitute F and H
B as I just described so the result is this so now we again have the
situation of F map a G of something dot under square one so that can
be simplified we have a fear of whatever it was here the applied to
this dot one so pure was the first argument of F map and G this was
the second argument of F naught a G so then we have this first argument
applied to the second argument dot underscore one now let\textsf{'}s see what
we can simply find here well we we can we need to substitute peer
and we need to substitute this we already know that in insert F of
H taken from map you really know we can simplify that so let\textsf{'}s want
to do that it\textsf{'}s an H taken from a pure and then this function which
is in SEF so we can combine them in into one function first applying
pure and then applying that to the result so that gives us this function
now this can be further simplified because that\textsf{'}s definition of pure
taking that one of this gives you just a so then basically this is
just an identity function and applying culture map of identity function
so this is just a dynasty function country map identity function is
identity so H a culture map of this is just H a so therefore we can
simplify our expression but using that this is just H a so then we
have pure very fa fa j dot one h a we can simplify this further by
inserting the definition of pure which is the tuple of this and pure
g of that so now we have the simplify this we can simplify anymore
because we don't know what pure gene does and we don't know what FA
does and what if a old age is so now let\textsf{'}s compare this has to be
equal to F a of H a because this entire thing must be an identity
function so identity function takes F a and returns again FA in other
words it must return a function at X H a and the plies FA to a chip
so that\textsf{'}s we expect to see just this instead we see this tuple what
is that - PO well this tuple has the first part from FHA now if a
of H a is itself a tuple let\textsf{'}s check that so FA of AJ is of type a
G of a so it\textsf{'}s a tuple and if this were equal to f AV J then this
should have been a favorite a dot underscore one comma F aah a dot
underscore two so instead of FA of H a dot underscore two we see this
how could this two things these two things be equal for arbitrary
a finucci it\textsf{'}s the same as to say that we have an arbitrary tuple
of this type and the second element of that tuple must be equal to
pure G of the first element of the tuple so the function pure G must
somehow be able to compute the second element of an arbitrary tuple
from the first element that\textsf{'}s impossible a tuple of two elements contains
information in both elements so this could be some arbitrary value
of type a this could be some arbitrary value of type G of a there\textsf{'}s
no possible way to compute a second value from the first in general
as long as the second value contains any non-trivial information as
long as it has more than one different value we couldn't possibly
guess what that value is given some other value unrelated to it it\textsf{'}s
all related because we don't know what there\textsf{'}s no constraint on the
function f a if a is an arbitrary function that takes H a and gives
a value of this type so the function f a gives an arbitrary value
of type a and then an arbitrary another value of times G of a they're
not relating these to the type of the type is like this so this is
G of a and that\textsf{'}s the same as here that\textsf{'}s just the type the values
are not related so it\textsf{'}s as long as the value of type G of a can be
more than one different now here we can posit we cannot possibly guess
or compute what it is so it\textsf{'}s impossible that this returns fa unless
there\textsf{'}s only one possible value in this type in other words G of a
contains no information there\textsf{'}s only one value of this type which
means it\textsf{'}s a unit type for away so G of a must be a trivial factor
constant factor that returns a unit type for all types a so in that
case pure G is just a function that returns unit and FA must have
been a function that returns a unit in the second point of the tuple
and we're done and it\textsf{'}s the identity law wouldn't hold just the first
part of the tuples is fine it\textsf{'}s the second part of the tuple that\textsf{'}s
broken so if G of a is unit then the second part of the tuple is always
unit and both identity laws hold so that conclude completes the proof
that this construction returns a full monad when G is unit in other
words when we don't have any gf and we can simply find a way product
with unit until just a so this completes the proof of all our constructions
let me give a brief overview of what we have found so first of all
these are not all possible constructions that give you a monad out
of something certain you can combine these constructions and you are
assured that you will get a monad as a result but there are other
there further constructions which I did not talk about which I know
and probably there are also constructions that I don't know there
isn't it seems a theory in the literature that explains to you what
are all possible constructions or what are all possible monads that
theory seems to be lacking in the literature at least I couldn't find
it I did a search online I made a question on Stack Overflow about
this but nobody seems to know so for example the question of how to
recognize a semi 1 ad or a monad from its type expression that seems
to be an open question in other words nobody knows the answer if I
give you some arbitrary type expression it\textsf{'}s not clear that you can
easily recognize that it\textsf{'}s a monad or not you can certainly try to
implement the methods pure and flatten there might be many implementations
of these of these that fit the types and then you you would have to
prove the flaws hold that\textsf{'}s a lot of work for any given type expression
it could be a huge amount of computation that is not easy and so it
doesn't seem to be an easy criterion however if you can build a monad
out of known constructions like these you're guaranteed that laws
hold and so there\textsf{'}s no need to check the laws so these constructions
give you examples of Vinod\textsf{'}s such as the constant function so again
for full model you need a unit but for semi wallet it can be just
any type a fixed type then you have a product of a and something which
is a semi model only a full model only when the identity monad is
considered so G is 1 so these are examples constant bonded identity
model and we have a product of two models but not the disjunction
or sometimes co-product as it is called you have a function from a
fixed type to a moment or same Amanat note that here you don't have
a function from a fixed type terminal if this is a moment that doesn't
help to make that a moment so recall we just proved that the identities
laws cannot hold unless G a is actually equal to one so if G a is
a moon at itself that doesn't help it needs to be actually equal to
one for this construction for this construction GA can be a moon odd
and then it\textsf{'}s a product of identity mullet and this moon up and the
product works so this is how it works and here you can have a function
from a fixed type to an arbitrary unit here not the fixed type is
a control factor so this construction contains a fixed type as an
option so if H a could be just some fixed type R but the right-hand
side must be of this form it must be a if you want to fool monad so
in this construction it\textsf{'}s a constant on the left but this can be an
arbitrary monad this construction is a free pointed so it gives you
another moment for a given what does this construction do for you
if you already have the moment why would you add a to it the reason
is this monad can be easily recognized as a value being pure or not
pure so in this mo not pure values are on the left and any non pure
values are on the right so any value that has an effect is on the
right and any value that doesn't have an effect is on the left so
I'm saying that a monadic value or a value of a monadic type has an
effect when it is not a result of applying pure to something so if
it if it\textsf{'}s equal to pure of something then that monadic value has
no effect as as empty effect in it that\textsf{'}s just an intuitive way of
talking about it it\textsf{'}s not really that we can recognize the presence
of an effect in a value except for this mode so in this model it\textsf{'}s
very easy to recognize the presence of an effect if it\textsf{'}s on the left
and there is no effect it wasn't a result of pure but on the right
then there is an effect so for example you start with pure you apply
some flat maps to it you could get this but if you just apply maps
to it then you would stay pure and in this mode it is easily recognizable
if a value is pure or not you can pattern match on the disjunction
and find out so maybe that is useful for certain applications to be
able to recognize by pattern matching whether a monadic value is pure
that this has an empty effect or it is not pure as some non-empty
effect and also note remember in the derivation of this we had a function
called merge which takes this and returns G of a so you can always
merge this a back into the monad G and that could be useful if Mona
Jie has some computational significance and this is just some extra
structure that you need temporarily for computation and then you can
get rid of it without losing any information or an emergent back so
that could be useful structure now this is a model where you substitute
the type parameter for another lunatic actually we have seen where
you will see in an exercise that this itself is the moon odd the combination
of writer monad and either moment so this is now a combination of
an arbitrary monad and this now this combination is interesting because
it\textsf{'}s a come it\textsf{'}s a functor composition of two minutes of G and of
this and so this is an interesting example where a functor composition
of two monads is again a monad this is by no means always the case
but there are some units such as this one such that a functor composition
of an arbitrary one at G and this mono is again a monad so that is
important to know that that such one else exists in a thesis a certain
class of Mona that have this property another class of Mona that have
similar property is this this is also a function composition of the
reader monad are two a and G of a but on in the opposite order so
G of a is inside the reader unit and here G of a is outside of this
moment so there this is a so reader belongs to a different class of
monads such that their functor composition with any other monad inside
is again a monad but this would not be the case if we use this moment
if you put G instead of here that would not work so this so the reader
madad and this linear type linear polynomial monad are of different
classes with respect to founder composition and that has relevance
for monad transformers which I will talk about in a later tutorial
now this construction is very important it\textsf{'}s a free madad over function
G and it gives you a mu nod out of an arbitrary function G no restrictions
on factor G so this is used a lot to obtain monads out of arbitrary
factors now the last two constructions are somewhat peculiar haven't
seen them in the literature much or at all I don't know if they have
names but so this construction is unfortunately only a semi mu not
it\textsf{'}s a tree with G shaped leaves and G shaped branches and this construction
is interesting because it gives you a monad out of an arbitrary control
function now control factors can be seen as type constructors that
have a function in them that consumes some values of type a let\textsf{'}s
say a general contractor can be a function from a functor to some
constant type let\textsf{'}s say my function from A to C or C is a constant
type or function from a functor G A to Z where Z is a constant type
so that\textsf{'}s a general kind of control factor of polynomial exponential
class of course I don't know if any other way of reasoning about types
except by talking about exponential polynomial types that is type
expressions that have function type disjunction and conjunction of
product so within this class of types all control factors can be seen
as functions from some G a let\textsf{'}s say to a constant type Z so an example
of this would be arbitrary factor G a going to Z all of that going
to a and that\textsf{'}s a moment for arbitrary control factor H a or if you
represent a chase through another factor then it will be a moon ad
for an arbitrary factor H now some G so this is another construction
that gives you a moon out of an arbitrary factor or an arbitrary control
factor I don't know yet what the use cases for those monads there
might be but at this point these are just the constructions that I
found and there are a few other constructions that come from one are
transformers but then you're almost general and they all require Mona
so there are no other constructions I know that take an arbitrary
factor which is itself not a unit or an arbitrary control function
and make a monad out of that these are these two constructions and
finally I don't think there is any such thing as a contaminant or
control function that is itself having a magnetic property I don't
think that is possible because a contractor such as H a consumes values
of a so the a inside the control factor are in the contravariant position
now monad structure would mean that you transform H of H of a into
H of a but if H is a control function then each of HIV is a functor
so because because a to contravariant positions cancel each other
it\textsf{'}s impossible to have a natural transformation between a contra
factor and D factor so there is no way that you could possibly have
a function such as flatten that takes F of F of a and returns F of
a where F is a contra factor just contravariance here and here is
different there is no way to have a natural transformation between
them between the founder and the control factor and so there\textsf{'}s no
way for you to implement flatten and so there is no analogue of contra
factors that are monads in any way moani\textsf{'}s must always be functors
so this concludes the theoretical part now the exercises let me make
some comments about the exercises so the first exercise is to complete
the proof that we started in the working examples we showed that this
is a semi group for a semi monad and semi group s but now if if in
a film or not you should show that this is a film on right even if
s is itself a mono it also for monoid the second exercise is a specific
example of one noted non-trivial monoid this exercise is to show explicitly
by symbolic code transformations this is a semi model you have to
implement F nap and flatten and peer notice here boo is a specific
type z is not but misses boo boo is a monoid so you can use any kind
of OneNote structure on boo the next exercise is to show that this
can be a semi woman but not a Mona no no yes this is actually equivalent
to a disjunction of MA and ma because boolean is just two values and
so you can expand the brackets and you get a disjunction so ma disjunction
of ma and ma is not a monad we know it\textsf{'}s a semi modem because we have
the construction that product instruction but it\textsf{'}s not a moaner so
sure that the laws don't hold next is again an exercise to showing
showing that one of them is emunah the other cannot be made into a
semi moment at this point is see this is a reader for that and we
compose readable not and the writer monad so we can pose it in one
order first the reader and then apply the writer to that or we first
take the writer and then apply the reader to them now this is construction
for so this can be made in the same way but I did not prove construction
for so you don't know that actually it will be exercise ten to verify
construction for so for this exercise just look at the types and see
which one can have the type of flatten that we require in other words
the type of flatten for this needs to be implemented can it be implemented
and can this be implemented and if so sure one of them expect this
one to be not sad because the type cannot be implemented so similarly
here show that you cannot implement the type necessary for a flat
map or or flatten whatever you choose now here P and Q are arbitrary
and different types you don't know anything about them so for specific
types maybe you could implement the same Emunah but not for the arbitrary
types in this exercise you have this type constructor which is just
this and you can implement Clanton and pure for it the types could
be implemented but the monado\textsf{'}s the knothole so the exercise for you
is to show that you can implement pure and you can implement flatten
in many ways so the exercise tells you to do it in at least two different
ways so these two different pure and at least two different flanking
but the laws never hold whatever whatever combination of those implementations
you take the Monad loads will not hold at least some of them will
fail in this exercise I don't expect you to enumerate all possible
implementations of pure and flatly and check that for all combinations
of these the laws fail but this is so there is a stack overflow question
about it which I initiated indeed not not I initiated somebody else
actually had a comment on something I said in some other question
and they asked this question so people have checked by explicit and
full calculation and I have checked it as well myself that no implementation
of pure and flatten for this type constructor will satisfy laws so
this is an example of a very simple type constructor which is a functor
but not a monad cannot be made into a monad for some obscure reasons
it\textsf{'}s not obvious why but something is missing on this type and you
cannot make a monad out of it next exercise is to check the laws now
for functor not a monad this the functor laws are what we discussed
in chapter 4 so this type constructor is actually not a function because
it is not covariant it it contains an alien a covariant position and
then a in a contravariant tradition so this is actually not a factor
not a country function either but for some obscure reason you can
implement a function f map that has the correct type signature this
is the code for it you should check that this has the right types
and so why is this possible well this is just some kind of accident
but imagine that the programmer didn't think about covariance here
and thought that this is this is my data type and I want F nap for
it and I can implement it great does that make this function you know
unless it satisfies the factor law so they the exercise is to show
it doesn't the next exercise is to check the Monad laws for this which
is similar to checking the Monad laws for for this except now instead
of boom you here you only verify the social Liberty and here you need
to verify everything and W must be a monoid then in this exercise
this is actually one of the constructions but the exercise is to write
down implementations for platinum pure explicitly and check the laws
now in this exercise it\textsf{'}s to show that pure so the construction 5
let me look at it within Islam so the construction 5 is this in this
construction when you find fewer for F as left of a now the exercise
here is to show that if we didn't and we defined it as right of Mona
G pure of a which we could have done conceivably because G is a monad
so we could put pure into the right part into here so show that if
we did that the one of the identity laws would fail so there\textsf{'}s no
way this would work in the next exercise the question is to take this
and find the constructions that you can use to construct this moment
and once you find it you already know that list is a monad for example
you don't need to check the laws so then you need to just implement
the monad methods for it and to do that we look at the constructions
and the constructions actually implement the Monad methods for each
step of the construction so you don't have to guess how to implement
a monad here because you have each step of the constructions showing
you how to implement flatten given previous monads implementation
but of course if you feel like guessing from scratch then you can
implement the Monad and methods for this for you from scratch in the
next exercise is to try the construction - which was this one in the
worked examples I showed I implemented this construction by discarding
the second effect in this exercise you should repeat that but they
start the first defense it would be a different implementation of
a semi Monnet and it\textsf{'}s still a semi Monat so you show it and it should
show that associativity is still satisfied for construction eight
in the next exercise I I did not show that associativity holds I just
showed that it cannot be a monad but I did not show that cannot be
a full Mona so it\textsf{'}s still a semi mode that only I did not show such
activity so you should show it in this exercise and finally not in
the last exercise you should revisit the standard known as the state
and a continuation moments from the first parts of the tutorial we
have verified the associativity laws for them but not the identity
laws so this exercise is to verify the identity loss for them good
luck with the exercises 
\end{comment}

